Nabble - io

Re: New website design

2009-11-04T01:27:21Z

On 2009-11-03, at 11:31 PM, Justin Poliey wrote:
> The only thing I'm not a huge fan of is the mouseover effect

I've changed it to use an underline - thanks.

Re: New website design

2009-11-04T01:00:46Z

On 2009-11-03, at 10:58 PM, Rich Collins wrote:
> Maybe my eyes are starting to fail me, but fonts are a bit small
> (10px).

Good point, I've upped it to 12px.

Re: New website design

2009-11-03T23:31:55Z

I agree that the type is a little too small, the size on the original
page fit much better. I do like the new layout though. The only thing
I'm not a huge fan of is the mouseover effect, but I guess that's just
nitpicking. Good work!

On Wed, Nov 4, 2009 at 1:58 AM, Rich Collins <richcollins@...> wrote:

> Maybe my eyes are starting to fail me, but fonts are a bit small
> (10px).
>
> On Nov 3, 2009, at 5:01 PM, Andreas Schipplock wrote:
>
>> looks clean, so it's good. I like the mouseover "effect" :).
>>
>> --
>> Kind regards,
>> Andreas Schipplock.
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Re: Package/environment management

2009-11-03T23:00:44Z

I think you should group some addons into a standard library. People
using Io for the first time might be put off that they need to figure
out how to "iopackage stevedekorte/socket" to fetch a url.

On Nov 3, 2009, at 5:08 PM, Steve Dekorte wrote:

>
> On 2009-11-02, at 9:57 PM, Justin Poliey wrote:
> > http://github.com/oleganza/iopackage/
> > IoPackage is a package management system that works on Git
> > repositories, and I don't doubt it could work with other packages
> > too. It hasn't been touched since February, so I think it's going
> > stale. Maybe a totally new project is best here?
> >
> > http://github.com/jdp/boid
> > Boid is an environment management system that works like
> virtualenv (http://pypi.python.org/pypi/virtualenv
> > ). What it does is create isolated environments of Io packages,
> > making it so you can use multiple versions of a package in different
> > scenarios depending on your needs.
>
> I agree that one is needed and like the idea of it integrated with
> github. For example, you could type:
>
> iopackage johnsmith/foobar
>
> and it would grab it from:
>
> git://github.com/johnsmith/foobar
>
> compile and install it. Git versions/branches could also be supported,
> etc. If we can get the basics working, I'd be happy to move all the
> current addons into their own guthub repos.
>
> Thoughts?
>
>
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/iolanguage/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/iolanguage/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:iolanguage-digest@...
mailto:iolanguage-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
iolanguage-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: New website design

2009-11-03T22:58:53Z

Maybe my eyes are starting to fail me, but fonts are a bit small
(10px).

On Nov 3, 2009, at 5:01 PM, Andreas Schipplock wrote:

> looks clean, so it's good. I like the mouseover "effect" :).
>
> --
> Kind regards,
> Andreas Schipplock.
>
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/iolanguage/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/iolanguage/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:iolanguage-digest@...
mailto:iolanguage-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
iolanguage-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: Package/environment management

2009-11-03T17:08:21Z

On 2009-11-02, at 9:57 PM, Justin Poliey wrote:

> http://github.com/oleganza/iopackage/
> IoPackage is a package management system that works on Git
> repositories, and I don't doubt it could work with other packages
> too. It hasn't been touched since February, so I think it's going
> stale. Maybe a totally new project is best here?
>
> http://github.com/jdp/boid
> Boid is an environment management system that works like virtualenv (http://pypi.python.org/pypi/virtualenv
> ). What it does is create isolated environments of Io packages,
> making it so you can use multiple versions of a package in different
> scenarios depending on your needs.

I agree that one is needed and like the idea of it integrated with
github. For example, you could type:

iopackage johnsmith/foobar

and it would grab it from:

git://github.com/johnsmith/foobar

compile and install it. Git versions/branches could also be supported,
etc. If we can get the basics working, I'd be happy to move all the
current addons into their own guthub repos.

Thoughts?

Re: New website design

2009-11-03T17:01:24Z

looks clean, so it's good. I like the mouseover "effect" :).

--
Kind regards,
Andreas Schipplock.

New website design

2009-11-03T16:46:31Z

The old nav was slot to traverse, so I tried to put all the links on
one page:

http://iolanguage.com/

feedback welcome

Can't get Yajl bindings to work

2009-11-03T12:30:39Z

I've outlined the whole problem here:
http://github.com/stevedekorte/io/issues#issue/7

Basically, I did a clean pull of Io, a clean pull of Yajl, then made and installed them both. When referencing Yajl in Io, Io gives an error about not being able to find libyajl.so.1. Steve then said I probably have to run ldconfig, which then results in ldconfig giving me errors about libiovmall.so. Anyone have a solution?

Thanks
Justin

Re: Package/environment management

2009-11-03T11:02:25Z

On Mon, Nov 2, 2009 at 11:50 PM, Danya Alexeyevsky <me.dendik@...> wrote:
> I'd rather support the idea of IOIMPORT (but I'd prefere it to be
> called IOPATH to be consistent with PATH, LD_LIBRARY_PATH,
> PYTHON_PATH, --ClassPath, etc). Approach with one directory with
> symlinks works well for systems administrator, but does not work if
> you have globally installed Io, you don't have root access and still
> want to add some addons.

You are mistaken; you still need IOPATH to use the symlinked approach
too. You can still have a centralized IOPKGS path and a user-specific
IOPKGS (or environment-specific, as others suggest). Link those paths
into IOPATH as appropriate.

These need not be competing systems.

--
Samuel A. Falvo II

Re: Package/environment management

2009-11-02T23:50:37Z

On Tue, Nov 3, 2009 at 9:14 AM, Samuel A. Falvo II <sam.falvo@...> wrote:
> On Mon, Nov 2, 2009 at 9:57 PM, Justin Poliey <jdp34@...> wrote:
>> What does everyone think?
>
> I haven't looked at the above, but I'm smitten with the approach
> GoboLinux manages its own packages, and it could be applied to other
> environments too.

I totally agree with Justin that Io _Needs_ a more flexible package
managment system.

I'd rather support the idea of IOIMPORT (but I'd prefere it to be
called IOPATH to be consistent with PATH, LD_LIBRARY_PATH,
PYTHON_PATH, --ClassPath, etc). Approach with one directory with
symlinks works well for systems administrator, but does not work if
you have globally installed Io, you don't have root access and still
want to add some addons.

-- Danya.

Re: Package/environment management

2009-11-02T23:44:31Z

> I haven't looked at the above, but I'm smitten with the approach
> GoboLinux manages its own packages, and it could be applied to other
> environments too.
>
> Let's imagine we define an environment variable IOPKGS, which points
> to the base path for all things Io-package related.
>
> Then, for any given Io package P, you have ${IOPKGS}/P/${P_VERSION} as
> a containing directory for the various source files and necessary
> subdirectories (e.g., in the case of GoboLinux, you see bin, etc, lib,
> usr, etc. in here).
>
> Then, each has a symbolic link ${IOPKGS}/P/current which points to
> ${IOPKGS}/P/${P_VERSION_OF_YOUR_CHOICE}
>
> In this manner, you are able to maintain as many different versions of
> P as you want.

And that works amazingly. But what if you want to have a specific
environment where a package depends on a specific older version of
another package though? You should be able to set up sandboxes for
each configuration.

I have to admit that my main concern when thinking about all this was
not necessarily packages in terms of tools and programs, but more like
pure-Io modules with the occasional binary. The current state of
making Io modules isn't very good, I feel it should be much easier.

> Next, we define a single directory containing symbolic links to all
> the installed packages' binaries.

Exactly, but instead of a multitude of symlinks to each individual
binary, how about a symlink to the path that contains all the
binaries, i.e., $IOPKGS/active/bin, where /active/ is a symlink to a
specific environment/sandbox.

> The package management system defines scripts (Io or shell, it doesn't
> really matter) which refreshes these symbolic links. This lets Io
> look in a _single_ directory for all installed packages, while
> preserving the ability to manage packages on their own terms.

I was thinking that would be $IOPKGS/active/io, with a directory
structure a little like:

Foo.io
Foo/
Subfile.io
AnotherSubfile.io
Bar.io
Bar/
Subfile.io

Allowing Foo.io and Bar.io to include those relative files with
doRelativeFile, and the importer would search for the Foo and Bar
protos in that $IOPKGS/active/io top-level.

Cheers
Justin

Re: Package/environment management

2009-11-02T22:14:43Z

On Mon, Nov 2, 2009 at 9:57 PM, Justin Poliey <jdp34@...> wrote:
> What does everyone think?

I haven't looked at the above, but I'm smitten with the approach
GoboLinux manages its own packages, and it could be applied to other
environments too.

Let's imagine we define an environment variable IOPKGS, which points
to the base path for all things Io-package related.

Then, for any given Io package P, you have ${IOPKGS}/P/${P_VERSION} as
a containing directory for the various source files and necessary
subdirectories (e.g., in the case of GoboLinux, you see bin, etc, lib,
usr, etc. in here).

Then, each has a symbolic link ${IOPKGS}/P/current which points to
${IOPKGS}/P/${P_VERSION_OF_YOUR_CHOICE}

In this manner, you are able to maintain as many different versions of
P as you want.

Next, we define a single directory containing symbolic links to all
the installed packages' binaries.

The package management system defines scripts (Io or shell, it doesn't
really matter) which refreshes these symbolic links. This lets Io
look in a _single_ directory for all installed packages, while
preserving the ability to manage packages on their own terms.

The only disadvantage to this system, as described, is its dependency
on POSIX filesystem semantics. You can work around this by, for
example, replacing that "big dump of symlinks" directory described
above with a simple text file, with each line pointing to a package
binary, etc.

Subdirectories would be supported, of course, so if you have
${IOPKGS}/P/bin/blah/foo.io, your symbolic link will point to
blah/foo.io and not just foo.io. This eases namespace management.

--
Samuel A. Falvo II

Package/environment management

2009-11-02T21:57:56Z

There needs to be a much better way to manage Io packages, at least those that are Io-based. It's still pretty annoying to go through the whole make addons/make install process for developing addons with C source, but there needs to be an easier way to manage Io packages that use pure Io.

Here are some already existing projects:

http://github.com/oleganza/iopackage/
IoPackage is a package management system that works on Git repositories, and I don't doubt it could work with other packages too. It hasn't been touched since February, so I think it's going stale. Maybe a totally new project is best here?

http://github.com/jdp/boid
Boid is an environment management system that works like virtualenv (http://pypi.python.org/pypi/virtualenv). What it does is create isolated environments of Io packages, making it so you can use multiple versions of a package in different scenarios depending on your needs.

I also had the idea that IOIMPORT environment variable should be respected by Importer, and directories in that variable will be added to the search path for Io imports. There is already a pull request waiting for that.

What does everyone think?

io

2009-11-02T10:32:21Z

JIT compilers offer slow startup - each method must be compiled before executing. Hot-spot offers quick startup - interpretation until methods are compiled. On compilers: LLVM is so quick, it is used for OpenCL.

Re: Re: Thought for the future of Io

2009-11-02T08:19:13Z

On 2009-11-02, at 11:15 AM, Friedrich Dominicus wrote:

> Another pointer which would be interesting, any tries
> undertaken to compile Io to "native" code?

This is what I'm doing with LLVM right now. Compiler emits LLVM IR,
second phase code generation takes that IR, and with the help of LLVM,
emits machine code, which can then be linked into a standalone binary,
or library.

> Regards
> Friedrich

Re: Re: Thought for the future of Io

2009-11-02T08:15:19Z

Steve Dekorte <steve@...> writes:

> On 2009-11-02, at 5:41 AM, Friedrich Dominicus wrote:
>> Have you tried it?
>
> Are you referring to LuaJIT 2, implementing Io in Lua, or implementing
> Io In Javascript?
In this case LuaJIT2, but I would be curious also how a Io/JavaScript
may look. Another pointer which would be interesting, any tries
undertaken to compile Io to "native" code?

Regards
Friedrich

--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Re: Re: Thought for the future of Io

2009-11-02T08:04:58Z

I want ahead of time compilation. So we can implement Io in itself,
and get a resulting binary, which the interpreter can then be built
in. It's either LLVM, roll my own (not going to do that) or emit GNU
assembler source for N processors (don't want to do that either). LLVM
at least gives me a way to emit just LLVM IR, and have the LLVM tools
emit the processor specific assembly which can then be linked into
machine code ahead of time.

On 2009-11-02, at 11:02 AM, Steve Dekorte wrote:

>
> On 2009-11-02, at 6:29 AM, Jeremy Tregunna wrote:
>> I looked at lua as an implementation language even before c or c++.
>> couldn't get the llvm bindings to build. :(
>
> What's the goal that llvm is needed for? If you want small size and/or
> high speed, Lua's vm+jit seems to fit the bill.
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Re: Re: Thought for the future of Io

2009-11-02T08:02:41Z

On 2009-11-02, at 6:29 AM, Jeremy Tregunna wrote:
> I looked at lua as an implementation language even before c or c++.
> couldn't get the llvm bindings to build. :(

What's the goal that llvm is needed for? If you want small size and/or
high speed, Lua's vm+jit seems to fit the bill.

Re: Re: Thought for the future of Io

2009-11-02T06:29:02Z

I looked at lua as an implementation language even before c or c++.
couldn't get the llvm bindings to build. :(

Regards,

Jeremy Tregunna
Mobile: +1 (519) 498-8299

Sent from my iPhone

On 2009-11-02, at 7:53 AM, Steve Dekorte <steve@...> wrote:

>
> Looking to alternative implementations of Io, at ~1/3 the speed of C,
> LuaJIT is looking pretty good:
>
> http://lua-users.org/lists/lua-l/2009-10/msg01098.html
>
> A Lua implementation of Io would remove the complexity of having to
> implement a garbage collector and would allow us to use Lua's more
> extensive set of bindings. It might also pave the way toward a
> Javascript implementation at some point.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Re: Re: Thought for the future of Io

2009-11-02T06:19:11Z

On 2009-11-02, at 5:41 AM, Friedrich Dominicus wrote:
> Have you tried it?

Are you referring to LuaJIT 2, implementing Io in Lua, or implementing
Io In Javascript?

Re: Re: Thought for the future of Io

2009-11-02T05:41:21Z

Steve Dekorte <steve@...> writes:

> Looking to alternative implementations of Io, at ~1/3 the speed of C,
> LuaJIT is looking pretty good:
>
> http://lua-users.org/lists/lua-l/2009-10/msg01098.html
>
> A Lua implementation of Io would remove the complexity of having to
> implement a garbage collector and would allow us to use Lua's more
> extensive set of bindings. It might also pave the way toward a
> Javascript implementation at some point.
Have you tried it?

Regards
Friedrich

Re: Re: Thought for the future of Io

2009-11-02T05:39:33Z

Currently only x86 CPUs are supported. x64 support is in the works.
Other architectures will follow with sufficient demand and/or
sponsoring.

http://luajit.org/faq.html

On Mon, 2009-02-11 at 04:53 -0800, Steve Dekorte wrote:
> Looking to alternative implementations of Io, at ~1/3 the speed of C,
> LuaJIT is looking pretty good:
>
> http://lua-users.org/lists/lua-l/2009-10/msg01098.html
>
> A Lua implementation of Io would remove the complexity of having to
> implement a garbage collector and would allow us to use Lua's more
> extensive set of bindings. It might also pave the way toward a
> Javascript implementation at some point.

--
--gh

Re: Re: Thought for the future of Io

2009-11-02T04:53:57Z

Looking to alternative implementations of Io, at ~1/3 the speed of C,
LuaJIT is looking pretty good:

http://lua-users.org/lists/lua-l/2009-10/msg01098.html

A Lua implementation of Io would remove the complexity of having to
implement a garbage collector and would allow us to use Lua's more
extensive set of bindings. It might also pave the way toward a
Javascript implementation at some point.

Re: Digest Number 1840

2009-11-01T22:47:38Z

Steve Dekorte <steve@...> writes:

> On 1 Nov 2009, at 12:40 am, Friedrich Dominicus wrote:
>>> ... I've seen at least one article, which says that Obj-C is what C++
>>> should have been.
>> That's absolutly something I would subscribe immediatly.
>
> Me too. I actually would have implemented Io in Objective-C if
> Objective-C was cross platform. (Btw, I know about the gnu Objective-
> C but it really isn't compatible with Apple's and I doubt it ever
> will be.)
Yes I'm afraid that's the case. But gnus objective C seems to work quite
similiar on every platform. But (this probably has to be written BUT),
the IDE support outside the Mac OS X is "near" non-existant. Please
don't tell me ProjectManager is the "answer".

>
>> Agreed Io has it's own kind of problems but it's really one of the
>> most
>> beatiful languages out there. I wish I had known it 11 years ago,
>> while
>> we were working on our own language. If we had known Io we surely
>> could
>> have tried to make it "compilable", and it would have been nice. I'm
>> sure.
>
> Thanks! What is that language you were working on?

It was named Q
http://www.q-software-solutions.de/q/index.shtml

It was thought as a follow-up to Eiffel with streng separation of
commands and queries. The queries should have been pure functional.
To that time I thought OO is the best invention since sliced bread and
that Eiffel is the "right" thing. To my shame I have to conclude, I'd
better had been fluent in Smalltalk, Common Lisp. Yes I've looked into
many languages but I ignored the "dynamically" typed ones. That wasn't
very clever. But that's not the most unclever point. My idea was that
people would be willing to buy software on Linux also. Oh boy, how could
one be so mistaken...

Regards
Friedrich

Re: asBlock

2009-11-01T16:07:50Z

Yes I was, thanks for the clarification.

On 2009-11-01, at 7:06 PM, Steve Dekorte wrote:

>
> On 2009-11-01, at 3:42 PM, Jeremy Tregunna wrote:
>> Doesn't this increase the likelihood of a block becoming a GC root?
>> And if so, is this still a problem in the GC where blocks may not be
>> collected if they become part of the root set?
>
> I'm guessing you're thinking of how locals (and their chain of
> locals / "stack frames") referenced by a block won't be collected
> while the block is referenced. It's only a problem if you put the
> block in a slot of a object that is kept around. The same would happen
> if you referenced a call or the sender in the same way.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Re: asBlock

2009-11-01T16:06:47Z

On 2009-11-01, at 3:42 PM, Jeremy Tregunna wrote:
> Doesn't this increase the likelihood of a block becoming a GC root?
> And if so, is this still a problem in the GC where blocks may not be
> collected if they become part of the root set?

I'm guessing you're thinking of how locals (and their chain of
locals / "stack frames") referenced by a block won't be collected
while the block is referenced. It's only a problem if you put the
block in a slot of a object that is kept around. The same would happen
if you referenced a call or the sender in the same way.

Re: asBlock

2009-11-01T15:42:54Z

Doesn't this increase the likelihood of a block becoming a GC root?
And if so, is this still a problem in the GC where blocks may not be
collected if they become part of the root set?

Regards,

Jeremy Tregunna
Mobile: +1 (519) 498-8299

Sent from my iPhone

On 2009-11-01, at 6:36 PM, Steve Dekorte <steve@...> wrote:

>
> If you've used a Call object you may have found that the code can get
> ugly when you deal with messages and contexts directly. So here's a
> method for Call that might help with this by wrapping the call into a
> block:
>
> Call asBlock := method(
> args := self message arguments
> b := Block clone setMessage(args last) setScope(sender)
> b setArgumentNames(args slice(args size - 2) map(name))
> b
> )
>
> // example use:
>
> List select := method(
> selected := List clone
> b := call asBlock
> self foreach(i, v,
> if(b call(i, v), selected append(v))
> )
> selected
> )
>
> list(1, 2, 3) select(i, v, v > 2) println
>
> Which leads us to the question: Should Call and block be unified?
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

asBlock

2009-11-01T15:36:53Z

If you've used a Call object you may have found that the code can get
ugly when you deal with messages and contexts directly. So here's a
method for Call that might help with this by wrapping the call into a
block:

Call asBlock := method(
args := self message arguments
b := Block clone setMessage(args last) setScope(sender)
b setArgumentNames(args slice(args size - 2) map(name))
b
)

// example use:

List select := method(
selected := List clone
b := call asBlock
self foreach(i, v,
if(b call(i, v), selected append(v))
)
selected
)

list(1, 2, 3) select(i, v, v > 2) println

Which leads us to the question: Should Call and block be unified?

Re: Re: Thought for the future of Io

2009-11-01T09:07:35Z

Yes they will. The way I'm thinking is that methods will be c
functions when compiled down. This would permit one to link a c
program against an io lib

Regards,

Jeremy Tregunna
Mobile: +1 (519) 498-8299

Sent from my iPhone

On 2009-11-01, at 11:14 AM, dennisf486 <dennisf486@...> wrote:

> --- In iolanguage@..., Jeremy Tregunna
> <jeremy.tregunna@...> wrote:
>>
>> Well, one wouldn't need the C addons anymore. Instead, one could
>> implement the addons in pure Io code using the FFI mechanism, which
>> as
>> I stated before would be needed, and would need to be fairly robust.
>
> I've been digging around a lot through all the addons' code recently
> and I wouldn't glibly assume they would all be so simple to
> replace. Certainly they could be reimplemented though.
>
> Fair enough; but maybe I posed my question poorly - I mainly brought
> up the addons as an example of C code that in turn calls Io VM
> functions. What I'm mainly concerned about is what about if one is
> embedding the Io VM in a C/C++ program. I assume the FFI would
> allow Io to call C functions; what I'm asking is will C functions be
> able to call compiled Io functions?
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Re: Thought for the future of Io

2009-11-01T08:14:16Z

--- In iolanguage@..., Jeremy Tregunna <jeremy.tregunna@...> wrote:
>
> Well, one wouldn't need the C addons anymore. Instead, one could
> implement the addons in pure Io code using the FFI mechanism, which as
> I stated before would be needed, and would need to be fairly robust.

I've been digging around a lot through all the addons' code recently and I wouldn't glibly assume they would all be so simple to replace. Certainly they could be reimplemented though.

Fair enough; but maybe I posed my question poorly - I mainly brought up the addons as an example of C code that in turn calls Io VM functions. What I'm mainly concerned about is what about if one is embedding the Io VM in a C/C++ program. I assume the FFI would allow Io to call C functions; what I'm asking is will C functions be able to call compiled Io functions?

Re: Re: Thought for the future of Io

2009-11-01T05:33:48Z

Well, one wouldn't need the C addons anymore. Instead, one could
implement the addons in pure Io code using the FFI mechanism, which as
I stated before would be needed, and would need to be fairly robust.

On 2009-11-01, at 12:16 AM, dennisf486 wrote:

> Just out of curiosity, how would the C binding work in that case? I
> assume actually launching an addon would not be a problem - you're
> just loading a DLL, which is fundementally an OS-supported call, but
> what about when the DLL attempts to manipulate Io objects using C
> code? Once you no longer use any C code to implement the Io
> interpreter, where will C functions like "UArray*
> UArray_newWithData_type_encoding_size_copy_(...)" be defined?
>
> One thing you might do, which seems to be in the spirit of what
> you're trying to accomplish here, is make a thin compatibility/shim
> library (in C) so that you can still compile the addons. Instead of
> the C functions in the shim library doing work on Io data structures
> directly, they would all be stub functions that call doString() on
> Io code that does the work. After all - now that you have Io
> written in Io, there's no need to keep the C version of the code
> around; and you probably wouldn't want to, because if you change the
> organization of your internal data structures the C version of Io
> would become out of date with respect to it.
>
> It's something I've debated on doing in my Io to C++ binding library
> - to replace most of my Io C API calls with calls to doString() & Io
> code (where possible).
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Re: Digest Number 1840

2009-11-01T01:07:39Z

On 1 Nov 2009, at 12:40 am, Friedrich Dominicus wrote:
>> ... I've seen at least one article, which says that Obj-C is what C++
>> should have been.
> That's absolutly something I would subscribe immediatly.

Me too. I actually would have implemented Io in Objective-C if
Objective-C was cross platform. (Btw, I know about the gnu Objective-
C but it really isn't compatible with Apple's and I doubt it ever
will be.)

> Agreed Io has it's own kind of problems but it's really one of the
> most
> beatiful languages out there. I wish I had known it 11 years ago,
> while
> we were working on our own language. If we had known Io we surely
> could
> have tried to make it "compilable", and it would have been nice. I'm
> sure.

Thanks! What is that language you were working on?

Re: Digest Number 1840

2009-11-01T00:40:51Z

Guy Hulbert <gwhulbert@...> writes:

> On Thu, 2009-29-10 at 08:18 -0700, Samuel A. Falvo II wrote:
>>
>> On Thu, Oct 29, 2009 at 6:35 AM, Mike O'Dell <mo@...> wrote:
>> > Apple *really* needs a programming language other than
>> > Objectionable-C for writing MacApps. to this end, they
>>
>> I think you mean "Objective-C".
I guess not, because the mail shows a dislike for Objective-C. Which I
can't understand. It's on of the really good extensions to C and it just
feels "right"
>
> Perhaps he means C++ ;-)
I wished, he did.

>
>>
>> As a C coder who is equally happy with Smalltalk, I find little to
>> complain about Objective-C, and really, REALLY, wish this kind of
>> slander would stop.
>
> It was new and funny to me ...
>
> ... I've seen at least one article, which says that Obj-C is what C++
> should have been.

That's absolutly something I would subscribe immediatly.

A "dream-duo" would be some IO/Objective-C I know there should something
in Io for that but I guess I never have been able to build it. Just
imagine instead of AppleScript we had Apple-Io. As we have MacRuby and
the like. I don't know if anyone has worked or tried automation with Io
on Apple, but I'm sure it would be nice.

Agreed Io has it's own kind of problems but it's really one of the most
beatiful languages out there. I wish I had known it 11 years ago, while
we were working on our own language. If we had known Io we surely could
have tried to make it "compilable", and it would have been nice. I'm
sure.

Regards
Friedrich

--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Re: Thought for the future of Io

2009-10-31T21:16:51Z

Just out of curiosity, how would the C binding work in that case? I assume actually launching an addon would not be a problem - you're just loading a DLL, which is fundementally an OS-supported call, but what about when the DLL attempts to manipulate Io objects using C code? Once you no longer use any C code to implement the Io interpreter, where will C functions like "UArray* UArray_newWithData_type_encoding_size_copy_(...)" be defined?

One thing you might do, which seems to be in the spirit of what you're trying to accomplish here, is make a thin compatibility/shim library (in C) so that you can still compile the addons. Instead of the C functions in the shim library doing work on Io data structures directly, they would all be stub functions that call doString() on Io code that does the work. After all - now that you have Io written in Io, there's no need to keep the C version of the code around; and you probably wouldn't want to, because if you change the organization of your internal data structures the C version of Io would become out of date with respect to it.

It's something I've debated on doing in my Io to C++ binding library - to replace most of my Io C API calls with calls to doString() & Io code (where possible).