Discussion:
What is the plan?
(too old to reply)
k***@ymail.com
2008-12-23 14:02:06 UTC
Permalink
It was around 2005 when I started to use C# 2.0; the Ruby trend was
coming up and I started to learn it! In fact I started to learn how a
language can help or harm. I have studied Haskell, F#, Lisp and even
JavaScript (Yes! I have started to understand it; yet I was using it a
long time before that)! There were other things too like Q (Qi is
another thing) and Python.

One of most interesting things to me was io! Yet it was somehow risky
to be used in product-environment. I was really in some levels of love
with io and said to myself: "It will be a stable plateform in at most
2 years from now" and I went on my daily job and I have lost io.

Recently I was playing with Clojure and suddenly I have remembered io!
I came back and almost nothing has changed much in 3 years!

What is the plan for io? I totally agree that io is more powerful than
both Ruby and Lisp; but I want to use it!

Note: And even you have not enough resource to work on io (which is a
piece of pure beauty thanks to you) at least change the name; it will
help so much! For example metaio! Because it is already metaio!

Cheers!
Guy Hulbert
2008-12-23 23:50:46 UTC
Permalink
Post by k***@ymail.com
What is the plan for io? I totally agree that io is more powerful than
both Ruby and Lisp; but I want to use it!
+1

[waiting for tuits]
--
--gh
Steve Dekorte
2008-12-24 00:44:21 UTC
Permalink
Post by k***@ymail.com
One of most interesting things to me was io! Yet it was somehow risky
to be used in product-environment. I was really in some levels of love
with io and said to myself: "It will be a stable plateform in at most
2 years from now" and I went on my daily job and I have lost io.
Recently I was playing with Clojure and suddenly I have remembered io!
I came back and almost nothing has changed much in 3 years!
What is the plan for io? I totally agree that io is more powerful than
both Ruby and Lisp; but I want to use it!
Hi Kaven,

You seem to be implying that Io isn't stable. Is there a specific bug
that you have run in to that we can fix?
Post by k***@ymail.com
Note: And even you have not enough resource to work on io (which is a
piece of pure beauty thanks to you) at least change the name; it will
help so much! For example metaio! Because it is already metaio!
Can you explain how changing the name be helpful? For example, what
resource do you need that you can not currently find via a search for
iolanguage or "io language"?

- Steve
Friedrich
2008-12-24 07:49:42 UTC
Permalink
Post by Steve Dekorte
Post by k***@ymail.com
One of most interesting things to me was io! Yet it was somehow risky
to be used in product-environment. I was really in some levels of love
with io and said to myself: "It will be a stable plateform in at most
2 years from now" and I went on my daily job and I have lost io.
Recently I was playing with Clojure and suddenly I have remembered io!
I came back and almost nothing has changed much in 3 years!
What is the plan for io? I totally agree that io is more powerful than
both Ruby and Lisp; but I want to use it!
Hi Kaven,
You seem to be implying that Io isn't stable. Is there a specific bug
that you have run in to that we can fix?
Post by k***@ymail.com
Note: And even you have not enough resource to work on io (which is a
piece of pure beauty thanks to you) at least change the name; it will
help so much! For example metaio! Because it is already metaio!
Can you explain how changing the name be helpful? For example, what
resource do you need that you can not currently find via a search for
iolanguage or "io language"?
- Steve
this question is well justified. I had not come along any bug in Io
since I'm using it. It had the suprise with foreach not opening a
new scope, but to may ashonishment ruby did it the same way. I could
not imagine that.

I think there are a few areas which could need improvement
especially. It's the numeric stuff. there should be some "native"
integer, but on the other hand having just one kind of Number (besides
BigNums) makes Io simpler. And with all respect to so many excellent
programmmers out there, the Sources for Io are extraordinarily
clean. I found just one "serious" drawback, not handling memory
allocation failures properly. I've posted some sort of "fix" to the
list, but can't tell if Steve has integrated them.
The other area would be a very decent IDE no Emacs does not count
because there is not such a think like gdb for Io. So this is another
area I really would appreciate enhancements. A decent debugger, whith
which one can step throuh code inspect variables and the like. I guess
the debug-hook might work somehow but that's an area I've still do not
get.

And I'm "dreaming" of an IoShell, in a way like zsh but programmable
and extensable with Io. This would be wonderful but having to write
Directory currentWorkingDirectory is a bit to verbose for that ;-)
Yes I know I can introduce cwd := .... but that would be needed for
quite a lot more Functions, although maybe the first handful would
cover nearly 80% of the day to day job. I guess I'd to think about it
;-)

Another thing which I'd like to have something like Rails or Seaside
for Io. And a decent book. I started to write one but have not come
yet beyond 30 or so pages. But if I hit hit the 100 page barrier I
will "go public" with it. I'm plannning on publishing it via lulu, and
I hope at least some will buy that book..... (hint, hint ;-)



I found the way Real World Haskell was written simply great. If I
just come near it or near the quality of Practical Common Lisp I'd be
very happy.....

Regards
Friedrich
--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
Samuel A. Falvo II
2008-12-24 08:15:35 UTC
Permalink
On Tue, Dec 23, 2008 at 11:49 PM, Friedrich
Post by Friedrich
The other area would be a very decent IDE no Emacs does not count
because there is not such a think like gdb for Io. So this is another
Io is positively resistant to IDE integration, for two reasons:

1) It's dynamically typed to the maximum possible extent. In order
for an IDE to provide the IDE-like features most people desire, you
need _either_ a static typing system to provide the editor with
knowledge about the program you're editing, _or_ you need a "live"
system (a la Smalltalk or Self), where the IDE and the application
co-reside and co-run.

2) Macros in Io are implemented with self-modifying code. How do you
account for this in the IDE Interface? Do you dynamically alter the
editor's interface? Or, do you use a separate debugger window which
provides a real-time image of the compiled code image? How often
should the display update? Etc.
--
Samuel A. Falvo II
Friedrich
2008-12-25 07:51:19 UTC
Permalink
Post by Samuel A. Falvo II
On Tue, Dec 23, 2008 at 11:49 PM, Friedrich
Post by Friedrich
The other area would be a very decent IDE no Emacs does not count
because there is not such a think like gdb for Io. So this is another
1) It's dynamically typed to the maximum possible extent. In order
for an IDE to provide the IDE-like features most people desire, you
need _either_ a static typing system to provide the editor with
knowledge about the program you're editing, _or_ you need a "live"
system (a la Smalltalk or Self), where the IDE and the application
co-reside and co-run.
Well it can be that dynamic as it likes, but even with a simply grep
through sources can one get quite much. A nice colouring is quite
helpful but the most important for an IDE is that it allows
debugging, and supports that well. Stepping through code must be as
easy as possible. I could even imagine something Smalltalk like for
browsing, I can not see why it should not be possible for a text based
system.

And getting help on some topic must not be out of reach. just an F1
on some identifier and you should find something. It does not have to
be perfect, but usable, and anything more than currently is quite an
enhancement.
Post by Samuel A. Falvo II
2) Macros in Io are implemented with self-modifying code. How do you
account for this in the IDE Interface? Do you dynamically alter the
editor's interface? Or, do you use a separate debugger window which
provides a real-time image of the compiled code image? How often
should the display update? Etc.
Well the Common Lisp people got it running and they do have Macros
in the tens of thousands. My idea would be one Io on the background
which does nothing but scanning through every other file but not the
one you are currently working on. You just use some heuristic for the
current buffer, e.g looking after method. Or maybe having one Object
in the background which represents the current state of the source.

I had my questions here on some area which I migh have use for. I
have a gtk based IDE and it works, it does not work perfect,but it
works and on Windows we have the current working. In the background
the code is compiled and compiled and compiled (with a C compiler) so
if you have typos the compiler points that out to you. I can not see
why something in Io should not be usable for that. Of course it must
be a small modification to cope with incomplete code, but we solved
that for C compilation and so someone good in Io should be able to do
for Io at least that good.

My idea is the following. Cleaning up the code and embed an Io in
it. You then can use Io to "drive" the IDE. the whold support first
probably will be to just scan text. It's used in etags, ctags for ages
and works quite ok, so it will work in any "text" based
environment. It does not get it right 100% but that's fine to me. A
support for well over 90% seems not require "rocket science.

In fact I'm hoping that one day I can have an Io based shell/window
manager/editor and simply live my live in it as I currentyl do with
Emacs. Of course I could always stick to Emacs and try to make the Io
stuff as "nice" as let's say the slime mode. I can not see why Io
should be "more" difficult as Common Lisp here.

But my preferences are first
1) get out some book about the Io language
2) wrapping the gtk stuff

I know that 1) will be quite hefty. I'm aware of the tiny market if
Io, but it's a very fascinating language. So maybe others may see it
someday....

I guess Haskell will surly gains through Real World haskell. All the
others introductions were way too "theoretic" but "develping
mulitmedia Applications with Haskell", another big winner on the book
market has been Practical Common Lisp, and we all know the C book from
Kernighan and Ritchie. Another winner was surely PickAxe. So there is
IMHO still the desire to get "books" about your favourite language.

A language which surely could gain from a good book is some
Smalltalk, unfortunatly all books about Squeak are simply besides
beeing "practical" they always tell you how to do things, but getting
into Morphs is simply pain. There's one online docu which seems to
cure that pain a bit:
http://squeak.preeminent.org/tut2007/html/index.html

That a bit extended in a book would probably do much good for Squeak.
--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
Samuel A. Falvo II
2008-12-25 17:19:02 UTC
Permalink
On Wed, Dec 24, 2008 at 11:51 PM, Friedrich
Post by Friedrich
Well the Common Lisp people got it running and they do have Macros
The Common Lisp macros are evaluated at read-time, not at run-time.
They can be identified statically. This is not so with Io -- you
cannot determine, with certainty, how a macro will expand without
actually executing the code tree in the method.
Post by Friedrich
A language which surely could gain from a good book is some
Smalltalk, unfortunatly all books about Squeak are simply besides
Unfortunately, Smalltalk had numerous books available at one time, and
did nothing to assist in its popularity.

Another good example is Forth -- here's a great language whose
popularity boomed in the early 80s, but waned heavily during the late
80s. Most people today have never heard of it.

However, one book for the Forth community, Thinking Forth, is
considered an all-time classic, applies to ALL languages (not just
Forth, though it uses Forth to illustrate its examples), and is now
available as open-documentation. It's called Thinking Forth, by Leo
Brodie. See http://thinking-forth.sourceforge.net/
--
Samuel A. Falvo II
k***@ymail.com
2008-12-24 08:21:29 UTC
Permalink
Thanks Friedrich! You have mentioned much of what I had in mind.

I think the first 3 things to have are:
1 - Stable integration with Apache
2 - Good integration with shell (like Ruby, on mainstream OSes).
3 - A good intro - pragmatic and practical

And enhancements/environments which are required can be:
1 - (An even very simple yet stable) debugger
2 - Fast all in one packed Io - like XAMPP or InstantRails
3 - Some focus on concurrency
4 - Rails!
Cliff Wells
2008-12-25 06:45:43 UTC
Permalink
Post by k***@ymail.com
Thanks Friedrich! You have mentioned much of what I had in mind.
1 - Stable integration with Apache
I'd prefer to see a more generic interface (i.e. FCGI). Not everyone
likes Apache ;-)
Post by k***@ymail.com
2 - Good integration with shell (like Ruby, on mainstream OSes).
3 - A good intro - pragmatic and practical
Maybe we could just start with "translating" an existing tutorial (say
from the Python or Ruby docs) and work from there?

This does bring up a related topic: how about getting a publicly
editable wiki going? A week or so of work by a few volunteers could
really change the face of the Io documentation. I'd be willing to host
it or we could use Google Sites.
Post by k***@ymail.com
1 - (An even very simple yet stable) debugger
2 - Fast all in one packed Io - like XAMPP or InstantRails
3 - Some focus on concurrency
What's wrong with the existing concurrency support? I'd say it's far
superior to Python and Ruby already. The only thing I'd like to see
working is working integration with libev or libevent (which I seem to
recall Steve committing some code for recently).

Regards,
Cliff
Scott Solmonson
2008-12-25 17:56:06 UTC
Permalink
Post by Cliff Wells
Post by k***@ymail.com
Thanks Friedrich! You have mentioned much of what I had in mind.
1 - Stable integration with Apache
I'd prefer to see a more generic interface (i.e. FCGI). Not everyone
likes Apache ;-)
I can go one further, and explain why I used plain old HTTP as the
interface for my appserver.
Last I checked, even the most common FCGI clients didn't support its
main benefit (asynchronous transaction pipelining)- so then you end up
with just another sequential listener on the backend which then might
be load-balanced and pooled to fix this and bleh- just dirty.
Direct HTTP on the other hand is even better supported, with all kinds
of proxies and load balancers able to work with it as well as the
ability to run bare to a browser.
Post by Cliff Wells
Post by k***@ymail.com
3 - Some focus on concurrency
What's wrong with the existing concurrency support? I'd say it's far
superior to Python and Ruby already.
My own issue with concurrency is still the "no threads" thing, which
means that to run a network server on an 8-core machine I need 8 IPs
and 8 VMs that don't share any internal data- or I have to stick them
behind a single apache etc- and then I have to explicitly bind each VM
to a core which is non-portable across OSes. I personally could get
by with just the ability to create soem threads, which I could then
utilize as a pool and let the OS do whatever the hell it wasn't with
them.
Post by Cliff Wells
The only thing I'd like to see
working is working integration with libev or libevent (which I seem to
recall Steve committing some code for recently).
I'm not sure what you mean by that- last I recall libevent was fully
exposed- I use direct FD access from within IO to talk to PostgreSQL's
c lib asynchronously.

-SS
Jeremy Tregunna
2008-12-25 18:15:22 UTC
Permalink
Post by Scott Solmonson
Post by Cliff Wells
Post by k***@ymail.com
3 - Some focus on concurrency
What's wrong with the existing concurrency support? I'd say it's far
superior to Python and Ruby already.
My own issue with concurrency is still the "no threads" thing, which
means that to run a network server on an 8-core machine I need 8 IPs
and 8 VMs that don't share any internal data- or I have to stick them
behind a single apache etc- and then I have to explicitly bind each VM
to a core which is non-portable across OSes. I personally could get
by with just the ability to create soem threads, which I could then
utilize as a pool and let the OS do whatever the hell it wasn't with
them.
I'm fixing this in Caribou. It's a primary focus for my Io
implementation.
Post by Scott Solmonson
Post by Cliff Wells
-SS
Regards,

Jeremy Tregunna
***@me.com
k***@ymail.com
2008-12-25 23:22:26 UTC
Permalink
Post by Jeremy Tregunna
I'm fixing this in Caribou. It's a primary focus for my Io
implementation.
So is the first step going Caribou?

( )
\ ) ( /
\/ \/
\ /
\_/
| `\
| |
| |
/--- |
( )
| ) |
| |
* *
Jeremy Tregunna
2008-12-26 03:57:08 UTC
Permalink
Well considering that I've only begun to write the bootstrap compiler,
it'll be a little while coming. The goal is to write an interpreter in
D, then build the language in itself generating C code which will
become the bootstrap compiler going forward, and then probably
generate LLVM IR from that and use the gcc frontend to build that down
to machine code for the final interpreter. So for the short term
anyway, there will be nothing of any value in it.
Post by k***@ymail.com
Post by Jeremy Tregunna
I'm fixing this in Caribou. It's a primary focus for my Io
implementation.
So is the first step going Caribou?
( )
\ ) ( /
\/ \/
\ /
\_/
| `\
| |
| |
/--- |
( )
| ) |
| |
* *
------------------------------------
Yahoo! Groups Links
Regards,

Jeremy Tregunna
***@me.com
k***@ymail.com
2008-12-25 23:29:23 UTC
Permalink
What about going on a VM? Parrot maybe?!

And take a look at ioke: io on JVM:
http://www.infoq.com/news/2008/11/ioke
Scott Solmonson
2008-12-26 05:00:09 UTC
Permalink
Post by k***@ymail.com
What about going on a VM? Parrot maybe?!
What do you see as the benefits of this?
ANSI C is already as portable as it gets, and is certainly fast, and
there's already GC built in (which seems to me to be the largest
benefit of what people call a VM)

-SS
Samuel A. Falvo II
2008-12-26 08:06:29 UTC
Permalink
Post by Scott Solmonson
What do you see as the benefits of this?
ANSI C is already as portable as it gets, and is certainly fast, and
there's already GC built in (which seems to me to be the largest
benefit of what people call a VM)
The portability of ANSI C leaves much to be desired. However, what
really made me cock an eyebrow is . . . there's already GC built in?

The last I checked, the *first* thing people think of when you mention
manual memory management is C.
--
Samuel A. Falvo II
k***@ymail.com
2008-12-26 10:51:08 UTC
Permalink
What do you see as the benefits of this (VM)?
As you have already mentioned one reason is GC; a stable GC which have
been tested in many situation, on many platforms, optimized and a team
of experts are taking care of it already; like GC in JVM.

Another benefit I see is the libraries. A huge bunch of libraries
already plugged into the VM.

To be honest that does not mean I am totally in love with VMs. This is
just something can put io a lot forward. Yet personally I like a shell
integrated io like what Ruby and Python are. But VMs helps to focus on
io itself not so many low level implementations (and is there already
an army of expert developers to make up a CPAN for io?).

Clojure is already doing well. Take a look at it. And may be I can
keep an eye on Ioke for sometime to see what would it do.

Parrot will come out on March 2009. I can not estimate how momentum
can it get. Yet it is an option.

And even io can be a little more abstracted from low levels by
employing well implemented environmental C libraries like LLVM.
Rich Collins
2008-12-26 15:34:58 UTC
Permalink
I wrote a Mongrel like server (using Mongrel's parser) in Io. You can
embed your Io code in it if you just want a simple HTTP server. See
addons/Volcano.
Post by k***@ymail.com
What do you see as the benefits of this (VM)?
As you have already mentioned one reason is GC; a stable GC which have
been tested in many situation, on many platforms, optimized and a team
of experts are taking care of it already; like GC in JVM.
Another benefit I see is the libraries. A huge bunch of libraries
already plugged into the VM.
To be honest that does not mean I am totally in love with VMs. This is
just something can put io a lot forward. Yet personally I like a shell
integrated io like what Ruby and Python are. But VMs helps to focus on
io itself not so many low level implementations (and is there already
an army of expert developers to make up a CPAN for io?).
Clojure is already doing well. Take a look at it. And may be I can
keep an eye on Ioke for sometime to see what would it do.
Parrot will come out on March 2009. I can not estimate how momentum
can it get. Yet it is an option.
And even io can be a little more abstracted from low levels by
employing well implemented environmental C libraries like LLVM.
k***@ymail.com
2008-12-25 23:17:43 UTC
Permalink
* I can go one further, and explain why I used plain old HTTP as the
* interface for my appserver.
* Last I checked, even the most common FCGI clients didn't support
* its main benefit (asynchronous transaction pipelining)- so then you
* end up ...

Indeed! Very true and thanks to mention it. So are you suggesting
doing something like YAWS in Erlang?

Before that io should be able to tackle with cores well enough.
Scott Solmonson
2008-12-26 05:07:24 UTC
Permalink
Post by k***@ymail.com
* I can go one further, and explain why I used plain old HTTP as the
* interface for my appserver.
* Last I checked, even the most common FCGI clients didn't support
* its main benefit (asynchronous transaction pipelining)- so then you
* end up ...
Indeed! Very true and thanks to mention it. So are you suggesting
doing something like YAWS in Erlang?
Yes and no (I've been saying that a lot).
When I built the specific appserver I focused on using it as part of
an entire platform.
(I live in the world of massively scalable distributed servers- Akamai
etc)
This means that the appserver is there to do only two things- run
code, and access external resources.
It was trivially easy to add direct file serving to it, both in pure
IO and by using the OS sendfile() call, but both were predictably
slower than using something closer to the metal like Apache or
lighttpd- and forcing a breakout between I/O-limited content (static)
and CPU/Network-limited content (app/externals) forces you to build an
app and a platform that is easily scalable.
So- no- there are already things that are better for serving static
content so they should be used- best tool for the job and all that :)

-SS
Cliff Wells
2008-12-26 00:44:59 UTC
Permalink
Post by Scott Solmonson
Post by Cliff Wells
Post by k***@ymail.com
Thanks Friedrich! You have mentioned much of what I had in mind.
1 - Stable integration with Apache
I'd prefer to see a more generic interface (i.e. FCGI). Not everyone
likes Apache ;-)
I can go one further, and explain why I used plain old HTTP as the
interface for my appserver.
Last I checked, even the most common FCGI clients didn't support its
main benefit (asynchronous transaction pipelining)- so then you end up
with just another sequential listener on the backend which then might
be load-balanced and pooled to fix this and bleh- just dirty.
Direct HTTP on the other hand is even better supported, with all kinds
of proxies and load balancers able to work with it as well as the
ability to run bare to a browser.
Post by Cliff Wells
Post by k***@ymail.com
3 - Some focus on concurrency
What's wrong with the existing concurrency support? I'd say it's far
superior to Python and Ruby already.
My own issue with concurrency is still the "no threads" thing, which
means that to run a network server on an 8-core machine I need 8 IPs
and 8 VMs that don't share any internal data- or I have to stick them
behind a single apache etc- and then I have to explicitly bind each VM
to a core which is non-portable across OSes. I personally could get
by with just the ability to create soem threads, which I could then
utilize as a pool and let the OS do whatever the hell it wasn't with
them.
I won't completely disagree with you. I will say that what you outline
above is arguably the best way to implement multiprocessing (including
the shared-nothing aspect) if scalability is your goal. What would be
nice is a way to make the above scheme a bit more transparent (and maybe
that's what you're saying).
Post by Scott Solmonson
Post by Cliff Wells
The only thing I'd like to see
working is working integration with libev or libevent (which I seem to
recall Steve committing some code for recently).
I'm not sure what you mean by that- last I recall libevent was fully
exposed- I use direct FD access from within IO to talk to PostgreSQL's
c lib asynchronously.
I didn't realize it was fully working (but there's a lot about Io I
don't know).

Cliff
Scott Solmonson
2008-12-26 04:58:01 UTC
Permalink
Post by Cliff Wells
Post by Scott Solmonson
My own issue with concurrency is still the "no threads" thing, which
means that to run a network server on an 8-core machine I need 8 IPs
and 8 VMs that don't share any internal data- or I have to stick them
behind a single apache etc- and then I have to explicitly bind each VM
to a core which is non-portable across OSes. I personally could get
by with just the ability to create soem threads, which I could then
utilize as a pool and let the OS do whatever the hell it wasn't with
them.
I won't completely disagree with you. I will say that what you outline
above is arguably the best way to implement multiprocessing (including
the shared-nothing aspect) if scalability is your goal. What would be
nice is a way to make the above scheme a bit more transparent (and maybe
that's what you're saying).
Well- yes and no- for my uses it's actually not that big of a deal to
have to have 8VMs and 8IPs, but it's just wasteful and complicates
things-
I'd rather have ONE config file, and ONE Lobby, and ONE version of
each Object I create, so that data that is shareable is done so
transparently, and data that is not shareable, I have to deal with.
The exact model I use is: 1 listening Socket, and a pool of
HTTPProtoHandlers.
Once a connection is received, an HTTPProtoHandler is pulled from the
pool which then reads the connection-
Once it has a valid HTTP request, it passes the request to an
HTTPRequestHandler (pulled from a similar pool) and returns itself to
the pool.
Then the HTTPRequestHandler does what it needs to with the request,
usually hitting a backend DB which is again handled the same way- a DB
connection is grabbed from a DBConn pool, the query is generated and
handed to it, it handles the query, returns the response, and returns
itself to the DBConn pool.
After the HTTPRequestHandler is done sending data to the client, it
returns itself to it's own pool and is ready to receive another request.
This all works fine and well, except it all happens in a single thread
on a single core (yes, everything is asynchronous throughout).
It would be beneficial to have each object in those pools in its own
thread so the OS could spread the load around the cores.
Post by Cliff Wells
Post by Scott Solmonson
Post by Cliff Wells
The only thing I'd like to see
working is working integration with libev or libevent (which I seem to
recall Steve committing some code for recently).
I'm not sure what you mean by that- last I recall libevent was fully
exposed- I use direct FD access from within IO to talk to
PostgreSQL's
c lib asynchronously.
I didn't realize it was fully working (but there's a lot about Io I
don't know).
Well- AFAIK all the FDs are exposed, so to work directly with libevent
that's all you need- there are like 5 different return codes that it
can give you so you just scan through all your FDs looking for
something that is ready to be read and issue that blocking request
only when you know it won't block.

-SS
Cliff Wells
2008-12-26 20:35:08 UTC
Permalink
Post by Scott Solmonson
Post by Cliff Wells
Post by Scott Solmonson
My own issue with concurrency is still the "no threads" thing, which
means that to run a network server on an 8-core machine I need 8 IPs
and 8 VMs that don't share any internal data- or I have to stick them
behind a single apache etc- and then I have to explicitly bind each VM
to a core which is non-portable across OSes. I personally could get
by with just the ability to create soem threads, which I could then
utilize as a pool and let the OS do whatever the hell it wasn't with
them.
I won't completely disagree with you. I will say that what you outline
above is arguably the best way to implement multiprocessing (including
the shared-nothing aspect) if scalability is your goal. What would be
nice is a way to make the above scheme a bit more transparent (and maybe
that's what you're saying).
Well- yes and no- for my uses it's actually not that big of a deal to
have to have 8VMs and 8IPs, but it's just wasteful and complicates
things-
Multiple VM's might waste a bit of RAM, but they make up for it
significantly on other overhead. For instance, Python has native
(OS-level) thread support, but performance suffers badly because there's
only one interpreter that runs on one CPU, so all threads contend for
that single important resource (hence the notorious Python Global
Interpreter Lock, aka GIL). There are alternatives but they all
significantly increase the complexity of the interpreter and also slow
it down significantly in the case of a single CPU (by around 30% IIRC).
This is why most scalable Python apps don't rely on threading alone, but
instead utilize a system similar to what you are doing (although Python
has some nice frameworks to make this more transparent).
Post by Scott Solmonson
I'd rather have ONE config file, and ONE Lobby, and ONE version of
each Object I create, so that data that is shareable is done so
transparently, and data that is not shareable, I have to deal with.
The exact model I use is: 1 listening Socket, and a pool of
HTTPProtoHandlers.
Once a connection is received, an HTTPProtoHandler is pulled from the
pool which then reads the connection-
Once it has a valid HTTP request, it passes the request to an
HTTPRequestHandler (pulled from a similar pool) and returns itself to
the pool.
Then the HTTPRequestHandler does what it needs to with the request,
usually hitting a backend DB which is again handled the same way- a DB
connection is grabbed from a DBConn pool, the query is generated and
handed to it, it handles the query, returns the response, and returns
itself to the DBConn pool.
After the HTTPRequestHandler is done sending data to the client, it
returns itself to it's own pool and is ready to receive another request.
This all works fine and well, except it all happens in a single thread
on a single core (yes, everything is asynchronous throughout).
It would be beneficial to have each object in those pools in its own
thread so the OS could spread the load around the cores.
I did some experimentation with running multiple Io VM's under both
pthreads and OpenMP. I posted the pthreads code on this list and
here's the OpenMP code:

http://pentropy.twisty-industries.com/running-multiple-io-vm-s-under-openmp

Clearly this is only a rudimentary beginning, but I think a path to
having a multithreaded Io interpreter doesn't seem out of reach. What
is needed is an easy way to send a message to an object over some form
of IPC. At that point messages could be sent back and forth between
VM's over IPC.

In any case, it seems that you might be able to achieve at least some of
your goals (single config, single main process to manage) from that
simple starting point.

Regards,
Cliff
Cliff Wells
2008-12-30 00:26:09 UTC
Permalink
Just for reference, I've hacked up a small set of programs to spawn an
arbitrary number of Io VM's, each running an HttpServer instance,
configured via a centralized DistributedObjects server, and provided an
example of using it all under Nginx:

http://pentropy.twisty-industries.com/multiple-io-vm-s-under-openmp-revisited


Hope that's of interest to someone.

Regards,
Cliff
Guy Hulbert
2008-12-30 11:55:26 UTC
Permalink
I've changed the subject. I hope that's ok (see Messages below).
Post by Cliff Wells
Just for reference, I've hacked up a small set of programs to spawn an
arbitrary number of Io VM's, each running an HttpServer instance,
configured via a centralized DistributedObjects server, and provided an
http://pentropy.twisty-industries.com/multiple-io-vm-s-under-openmp-revisited
Hope that's of interest to someone.
Yes. But I haven't had time to even try building Io yet.

I had a private discussion with someone about MPI on Io a few weeks ago.
I can't remember the difference between openmp and mpi at the moment.
Post by Cliff Wells
Regards,
Cliff
[snip]
Post by Cliff Wells
Messages in this topic (50) Reply (via web post) | Start a new
--gh
Guy Hulbert
2008-12-30 12:04:05 UTC
Permalink
Post by Guy Hulbert
I had a private discussion with someone about MPI on Io a few weeks ago.
I can't remember the difference between openmp and mpi at the moment.
Ok: http://en.wikipedia.org/wiki/OpenMP

I understand that mpi may be a better choice but as far as I'm
concerned, there is no difference between mpi and openmp. I'm mainly
interested in what's required to make Io run transparently on multiple
cores (as, I believe, erlang but nothing else does).
--
--gh
Guy Hulbert
2008-12-30 12:25:08 UTC
Permalink
I've changed the subject. I hope that's ok (see Messages below).
Post by Cliff Wells
Just for reference, I've hacked up a small set of programs to spawn an
arbitrary number of Io VM's, each running an HttpServer instance,
configured via a centralized DistributedObjects server, and provided an
http://pentropy.twisty-industries.com/multiple-io-vm-s-under-openmp-revisited
Post by Cliff Wells
Hope that's of interest to someone.
Very cool.

How much more difficult do you think it would be to eliminate Nginx and
the extra ports? If you could detect the number (N) of cores and have
the behaviour default to '-n N' then it would be transparent.

In python there is an smtpd, which is built on top of asyncore so that
the smptd, itself, is quite simple (even I can understand it ;-). Iirc,
asyncore is also used for an http server but python has a GIL, which is
still present in 3.0 (and in stackless).
--
--gh
Steve Dekorte
2008-12-30 12:55:55 UTC
Permalink
Post by Guy Hulbert
How much more difficult do you think it would be to eliminate Nginx and
the extra ports? If you could detect the number (N) of cores and have
the behaviour default to '-n N' then it would be transparent.
Just a note: It's not well documented but you should be able to do
that example within Io (no need for custom C code).

You can get the number of cores like this:

System activeCpus

And spawn VMs with their own OS thread like this:

Thread createThread("//some Io code")

- Steve
Guy Hulbert
2008-12-30 13:11:46 UTC
Permalink
Post by Steve Dekorte
Just a note: It's not well documented but you should be able to do
that example within Io (no need for custom C code).
I had gathered that.
Post by Steve Dekorte
System activeCpus
And spawn VMs with their own OS thread
One hopes to avoid multiple VMs but I suppose with Io the overhead might
be so small it would not be necessary.

I know there is some interest in Io on Parrot. Ideally one could write
an asynchronous server in pure Io which would run both on Parrot and
natively and use all cores available. It seems that something like
asyncore.py would be useful in any case.
--
--gh
Guy Hulbert
2008-12-30 15:40:02 UTC
Permalink
Post by Steve Dekorte
System activeCpus
Thread createThread("//some Io code")
- Steve
BTW, thanks Steve that's very useful.
--
--gh
Cliff Wells
2008-12-30 17:44:54 UTC
Permalink
Post by Steve Dekorte
Thread createThread("//some Io code")
So does Thread create a new VM as a side effect or would VM creation be
left to the threaded code?

Cliff
Steve Dekorte
2008-12-30 23:10:01 UTC
Permalink
Post by Cliff Wells
So does Thread create a new VM as a side effect
Yes. It creates the VM, and evals the string passed to the
createThread() method in that VM using the new thread. It should also
clean up the VM when the Thread object is collected.

Btw, IoVM's can only have one OS thread in them at a time so using a
VM per thread/process is the only way to get multi-core concurrency
for executing Io code.
Cliff Wells
2008-12-30 23:22:03 UTC
Permalink
Post by Steve Dekorte
Post by Cliff Wells
So does Thread create a new VM as a side effect
Yes. It creates the VM, and evals the string passed to the
createThread() method in that VM using the new thread. It should also
clean up the VM when the Thread object is collected.
Great.
Post by Steve Dekorte
Btw, IoVM's can only have one OS thread in them at a time so using a
VM per thread/process is the only way to get multi-core concurrency
for executing Io code.
I'd expect that's the only efficient way in any case. Sharing an
interpreter across threads is of limited utility.

Regards,
Cliff
Guy Hulbert
2008-12-30 23:54:57 UTC
Permalink
Post by Steve Dekorte
Btw, IoVM's can only have one OS thread in them at a time so using a
VM per thread/process is the only way to get multi-core concurrency
for executing Io code.
Is this constraint (a VM per OS thread) fixed ?

I'm really confused now. I shall look at the documentation (and code).

I had imagined writing coroutines and having them run transparently on
multiple cores but I assumed that the relationship between VM and
interpreter was the same as other languages (java, perl, python, ruby).
I probably don't understand those sufficiently either but I believe they
are all similar (stack-based) -- Parrot is register-based (like modern
CPUs). It seems that Io must also be different somehow.
Post by Steve Dekorte
I'd expect that's the only efficient way in any case. Sharing an
interpreter across threads is of limited utility.
I don't think that I'm the only one unclear about this. Steve said
one thread per VM, not interpreter.

I'm also unsure about what "OS thread" means here. Solaris has kernel
threads and user-space threads[1]. Perl had several choices of thread
models at one time but those threads would have been implemented in
libraries (like Solaris' user-space ones). I know that Linux now has
kernel threads but I believe the implementation is somewhat different
from solaris.

Apologies for venting my ignorance here ...

[1] Sun published a book on threaded programming in the early 1990s
which I read at the time but I can't find to reference. It compares
solaris to NT and OS/2.
--
--gh
Jeremy Tregunna
2008-12-31 01:11:44 UTC
Permalink
Post by Guy Hulbert
Post by Steve Dekorte
Btw, IoVM's can only have one OS thread in them at a time so using a
VM per thread/process is the only way to get multi-core concurrency
for executing Io code.
Is this constraint (a VM per OS thread) fixed ?
Yes. There can only be one VM per OS thread. Io itself is not
multithreaded, though it is thread safe.
Post by Guy Hulbert
I'm really confused now. I shall look at the documentation (and code).
I had imagined writing coroutines and having them run transparently on
multiple cores but I assumed that the relationship between VM and
interpreter was the same as other languages (java, perl, python, ruby).
I probably don't understand those sufficiently either but I believe they
are all similar (stack-based) -- Parrot is register-based (like modern
CPUs). It seems that Io must also be different somehow.
Coroutines (Knuth) are by nature singly threaded. However, it's not
entirely impossible to make coros take advantage of multiple
processors, it just seems kind of silly.
Post by Guy Hulbert
Post by Steve Dekorte
I'd expect that's the only efficient way in any case. Sharing an
interpreter across threads is of limited utility.
I don't think that I'm the only one unclear about this. Steve said
one thread per VM, not interpreter.
One VM per thread, one interpreter per VM. Io's VM is a tree walker,
the interpreter is tied to the VM and visa-versa.
Post by Guy Hulbert
I'm also unsure about what "OS thread" means here. Solaris has kernel
threads and user-space threads[1]. Perl had several choices of thread
models at one time but those threads would have been implemented in
libraries (like Solaris' user-space ones). I know that Linux now has
kernel threads but I believe the implementation is somewhat different
from solaris.
OS thread means the operating system's heavyweight threads (usually
kernel-level). One cannot implement user-level OS threads without one
of two things: 1) Interfacing with the kernel to achieve it, or 2)
Utilizing the user-level exposed threading library the kernel provides
(i.e., POSIX Threads API).
Post by Guy Hulbert
Apologies for venting my ignorance here ...
[1] Sun published a book on threaded programming in the early 1990s
which I read at the time but I can't find to reference. It compares
solaris to NT and OS/2.
--
--gh
------------------------------------
Yahoo! Groups Links
Regards,

Jeremy Tregunna
***@me.com
Cliff Wells
2008-12-30 17:30:06 UTC
Permalink
Post by Guy Hulbert
I've changed the subject. I hope that's ok (see Messages below).
Post by Cliff Wells
Just for reference, I've hacked up a small set of programs to spawn an
arbitrary number of Io VM's, each running an HttpServer instance,
configured via a centralized DistributedObjects server, and provided an
http://pentropy.twisty-industries.com/multiple-io-vm-s-under-openmp-revisited
Post by Cliff Wells
Hope that's of interest to someone.
Very cool.
How much more difficult do you think it would be to eliminate Nginx and
the extra ports?
I considered this. You'd need a single process to handle the external
network layer and proxy it to the subprocesses. The upside is making
the whole thing entirely self-contained, the downside is a probable
performance hit and code complication. I think that it should be done,
if the goal is a *general* solution, but for just HTTP, you'll certainly
want to use a traditional HTTP server (such as Apache, Lighty or Nginx)
to handle static content in any case, so the additional cost is minimal.
In other words, it might not "feel" like the right solution, but it
probably is, in terms of performance and scalability.
Post by Guy Hulbert
If you could detect the number (N) of cores and have
the behaviour default to '-n N' then it would be transparent.
OpenMP has automatic core detection (and in fact, my demonstration
program uses it if you don't specify the number via the -n switch).
Post by Guy Hulbert
In python there is an smtpd, which is built on top of asyncore so that
the smptd, itself, is quite simple (even I can understand it ;-). Iirc,
asyncore is also used for an http server but python has a GIL, which is
still present in 3.0 (and in stackless).
Yes, but those still only use a single CPU to run the interpreter (and
asyncore itself is not threaded, so smtpd is completely limited to a
single CPU in any case). Also, since we're discussing Python, GvR has
made it pretty clear that removing the GIL will probably never happen
(due to the performance impact on single-threaded apps) and in fact
recommends scaling Python across CPU's by forking multiple VM's.

Regards,
Cliff
Guy Hulbert
2008-12-30 18:11:31 UTC
Permalink
Post by Cliff Wells
Post by Guy Hulbert
In python there is an smtpd, which is built on top of asyncore so that
the smptd, itself, is quite simple (even I can understand it ;-). Iirc,
asyncore is also used for an http server but python has a GIL, which is
still present in 3.0 (and in stackless).
Yes, but those still only use a single CPU to run the interpreter (and
asyncore itself is not threaded, so smtpd is completely limited to a
single CPU in any case). Also, since we're discussing Python, GvR has
made it pretty clear that removing the GIL will probably never happen
(due to the performance impact on single-threaded apps) and in fact
recommends scaling Python across CPU's by forking multiple VM's.
Yup ... that's why I'm reading this list ... see "but" above.

Since I wrote the above, I've noticed "async sockets" on the io
documentation page so perhaps most of the work is done already.
--
--gh
A.M.
2008-12-30 19:34:30 UTC
Permalink
Post by Cliff Wells
Post by Guy Hulbert
I've changed the subject. I hope that's ok (see Messages below).
Post by Cliff Wells
Just for reference, I've hacked up a small set of programs to
spawn an
Post by Guy Hulbert
Post by Cliff Wells
arbitrary number of Io VM's, each running an HttpServer
instance,
Post by Guy Hulbert
Post by Cliff Wells
configured via a centralized DistributedObjects server, and
provided
Post by Guy Hulbert
Post by Cliff Wells
an
http://pentropy.twisty-industries.com/multiple-io-vm-s-under-openmp-revisited
Post by Cliff Wells
Hope that's of interest to someone.
Very cool.
How much more difficult do you think it would be to eliminate
Nginx and
Post by Guy Hulbert
the extra ports?
I considered this. You'd need a single process to handle the external
network layer and proxy it to the subprocesses. The upside is making
the whole thing entirely self-contained, the downside is a probable
performance hit and code complication. I think that it should be done,
if the goal is a *general* solution, but for just HTTP, you'll
certainly
want to use a traditional HTTP server (such as Apache, Lighty or Nginx)
to handle static content in any case, so the additional cost is minimal.
In other words, it might not "feel" like the right solution, but it
probably is, in terms of performance and scalability.
It is possible to pass file descriptors over unix domain sockets- no
proxy necessary.

http://www.myelin.co.nz/post/2003/12/2/
http://blog.henning.makholm.net/2008/06/unix-domain-socket-woes.html

Cheers,
M
Cliff Wells
2008-12-30 20:29:22 UTC
Permalink
Post by A.M.
Post by Cliff Wells
Post by Guy Hulbert
I've changed the subject. I hope that's ok (see Messages below).
Post by Cliff Wells
Just for reference, I've hacked up a small set of programs to
spawn an
Post by Guy Hulbert
Post by Cliff Wells
arbitrary number of Io VM's, each running an HttpServer
instance,
Post by Guy Hulbert
Post by Cliff Wells
configured via a centralized DistributedObjects server, and
provided
Post by Guy Hulbert
Post by Cliff Wells
an
http://pentropy.twisty-industries.com/multiple-io-vm-s-under-openmp-revisited
Post by Cliff Wells
Hope that's of interest to someone.
Very cool.
How much more difficult do you think it would be to eliminate
Nginx and
Post by Guy Hulbert
the extra ports?
I considered this. You'd need a single process to handle the external
network layer and proxy it to the subprocesses. The upside is making
the whole thing entirely self-contained, the downside is a probable
performance hit and code complication. I think that it should be done,
if the goal is a *general* solution, but for just HTTP, you'll certainly
want to use a traditional HTTP server (such as Apache, Lighty or Nginx)
to handle static content in any case, so the additional cost is minimal.
In other words, it might not "feel" like the right solution, but it
probably is, in terms of performance and scalability.
It is possible to pass file descriptors over unix domain sockets- no
proxy necessary.
http://www.myelin.co.nz/post/2003/12/2/
http://blog.henning.makholm.net/2008/06/unix-domain-socket-woes.html
You still need a proxy in this case, just not an external one or one
that communicates over TCP. *Something* has to handle and disperse the
incoming requests (file descriptors in this case) to the various backend
processes. So really it's a matter of choosing whether to use an
existing external proxy or writing it yourself as part of your
application.

The latter has the benefit of bundling the proxy and backends up into a
neat package that hides the fact they are separate processes.

However, my thinking is that you will probably want to serve static
content as well (images, css, js, etc), and something like Nginx or
Lighty is going to do it much more efficiently than something written in
a dynamic language can. That being the case, you may as well use it as
a proxy as well since it makes life a bit simpler. Also, you get to
take advantage of a well-tested code base.

I'm certainly not discouraging anyone from writing such a proxy (in
fact, that's what I'm hacking on at the moment, mostly for fun, and I'll
probably try your sockets approach), but I don't think such a solution
is really required or offers any performance benefits over using an
traditional external proxy.

Regards,
Cliff
Guy Hulbert
2008-12-30 21:18:50 UTC
Permalink
Post by Cliff Wells
You still need a proxy in this case, just not an external one or one
that communicates over TCP. *Something* has to handle and disperse the
incoming requests (file descriptors in this case) to the various
There is a very nice description of how an async server works, in
connection with the python smtpd. I think it's on the twisted website.
That's the "*something*". However, you probably know this (lighty is
async, iirc).

[snip]
Post by Cliff Wells
However, my thinking is that you will probably want to serve static
content as well (images, css, js, etc), and something like Nginx or
Lighty is going to do it much more efficiently than something written in
a dynamic language can. That being the case, you may as well use it as
a proxy as well since it makes life a bit simpler. Also, you get to
take advantage of a well-tested code base.
So why write an http server in the first place ?

[snip]
Post by Cliff Wells
probably try your sockets approach), but I don't think such a solution
is really required or offers any performance benefits over using an
traditional external proxy.
This approach (dynamic language) has been found to work very well for
dealing with spam and for high traffic sites an async smtp server seems
to be essential. I suspect that one could dream up a situation where
the same problem arises for http.

A clean sockets solution, would be nice to have ... Io looks nicer than
erlang ;-)
Post by Cliff Wells
Regards,
Cliff
--
--gh
Cliff Wells
2008-12-30 23:35:42 UTC
Permalink
Post by Guy Hulbert
Post by Cliff Wells
You still need a proxy in this case, just not an external one or one
that communicates over TCP. *Something* has to handle and disperse the
incoming requests (file descriptors in this case) to the various
There is a very nice description of how an async server works, in
connection with the python smtpd. I think it's on the twisted website.
That's the "*something*". However, you probably know this (lighty is
async, iirc).
Yes, but async implies single-threaded. This means that a single async
application on its own will only utilize a single core. Most async
servers that utilize multiple cores do so by having a single "master"
process that dispatches to multiple worker processes. In this case the
"master" would play the role of what I am terming "proxy". I'm
suggesting that for HTTP applications, Nginx (or a similar
load-balancing proxy) makes a fine master process.
Post by Guy Hulbert
[snip]
Post by Cliff Wells
However, my thinking is that you will probably want to serve static
content as well (images, css, js, etc), and something like Nginx or
Lighty is going to do it much more efficiently than something written in
a dynamic language can. That being the case, you may as well use it as
a proxy as well since it makes life a bit simpler. Also, you get to
take advantage of a well-tested code base.
So why write an http server in the first place ?
Because it's an easy, portable way for an application to communicate
with a traditional HTTP server or proxy. It's a protocol, nothing
more.
Post by Guy Hulbert
Post by Cliff Wells
probably try your sockets approach), but I don't think such a solution
is really required or offers any performance benefits over using an
traditional external proxy.
This approach (dynamic language) has been found to work very well for
dealing with spam and for high traffic sites an async smtp server seems
to be essential. I suspect that one could dream up a situation where
the same problem arises for http.
A clean sockets solution, would be nice to have ... Io looks nicer than
erlang ;-)
I'm all for async (which is one of many reasons I use Nginx rather than
Apache). But I believe that's pretty much what Io has already with its
coroutines. The concern isn't so much about whether to use async, it's
about how to manage multiple async applications in a sane way (that is,
get the benefits of both async and multiprocess).

BTW, I'm having a difficult time deciding if we are agreeing or not ;-)

Regards,
Cliff
Guy Hulbert
2008-12-31 00:02:55 UTC
Permalink
On Tue, 2008-30-12 at 15:35 -0800, Cliff Wells wrote:
[snip]
That's the "*something*". However, you probably know this (lighty is
async, iirc).
Yes, but async implies single-threaded. This means that a single async
I don't believe this is correct in general. I'm not an expert though.
There is an interesting discussion of multi-processing models in the
Parrot documentation (they looked closely at Io when working out the
requirements).

[snip]
So why write an http server in the first place ?
Because it's an easy, portable way for an application to communicate
with a traditional HTTP server or proxy. It's a protocol, nothing
more.
Ok.

[snip]
BTW, I'm having a difficult time deciding if we are agreeing or not ;-)
I'm not always arguing ... some of my questions are purely to reduce my
own ignorance.

I like the asyncore/smtpd implementation in python. It seems to be the
right approach. It separates the protocol from the underlying details
very cleanly.

However, python won't use multiple cores without a fight ...

--gh
Rich Collins
2008-12-31 00:07:00 UTC
Permalink
You get one interpreter per thread. Each interpreter contains
separate coroutines (and state). AFAIK, the only way ATM to
communicate between the interpreters is to use sockets.
Post by Guy Hulbert
[snip]
That's the "*something*". However, you probably know this
(lighty is
async, iirc).
Yes, but async implies single-threaded. This means that a single
async
I don't believe this is correct in general. I'm not an expert though.
There is an interesting discussion of multi-processing models in the
Parrot documentation (they looked closely at Io when working out the
requirements).
[snip]
So why write an http server in the first place ?
Because it's an easy, portable way for an application to communicate
with a traditional HTTP server or proxy. It's a protocol, nothing
more.
Ok.
[snip]
BTW, I'm having a difficult time deciding if we are agreeing or not ;-)
I'm not always arguing ... some of my questions are purely to reduce my
own ignorance.
I like the asyncore/smtpd implementation in python. It seems to be the
right approach. It separates the protocol from the underlying details
very cleanly.
However, python won't use multiple cores without a fight ...
--gh
Guy Hulbert
2008-12-31 00:36:14 UTC
Permalink
Post by Rich Collins
You get one interpreter per thread. Each interpreter contains
separate coroutines (and state). AFAIK, the only way ATM to
communicate between the interpreters is to use sockets.
Thanks. That seems consistent with what I've been hearing. My problem
is that I don't understand exactly what "interpreter", "VM", and
"thread" mean. The documentation (see below) indicates that some of
these terms may not be a very precise way to talk about Io.
Post by Rich Collins
Post by Steve Dekorte
Btw, IoVM's can only have one OS thread in them at a time so using a
VM per thread/process is the only way to get multi-core concurrency
for executing Io code.
Is this constraint (a VM per OS thread) fixed ?
The answer to this (below) appears to be "no", since the documentation
says "should" rather than "can't". Steve's recent comment is presumably
more authoritative than the documentation but there seems to be some
flexibility.
Post by Rich Collins
I'm really confused now. I shall look at the documentation (and code).
Here is the relevent section of the documentation.

http://iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html#Embedding-IoState

IoState

An IoState can be thought of as an instance of an Io "virtual
machine", although "virtual machine" is a less appropriate term
because it implies a particular type of implementation.

Multiple states

Io is multi-state, meaning that it is designed to support
multiple state instances within the same process. These
instances are isolated and share no memory so they can be safely
accessed simultaneously by different os threads, though a given
state should only be accessed by one os thread at a time.

I still don't understand "os threads". I understand threads to be
mini-processes but being entirely contained within one program so I
don't understand what a "state" being "accessed" by one os thread means.

This section of the documentation is under Embedding and discusses the C
implementation while my "understanding" above is from the Io side. A
diagram may help ... even if I have to read the code and draw it
myself ;-).


--gh
Samuel A. Falvo II
2008-12-31 00:45:41 UTC
Permalink
Post by Guy Hulbert
I still don't understand "os threads". I understand threads to be
A "thread" is a virtual microprocessor instance -- it contains its own
copy of CPU and FPU registers, and runs inside some address space.
Threads are abstractions provided by the operating system. They
utilize resources and communicate with other threads via operating
system calls, such as sockets.
Post by Guy Hulbert
mini-processes but being entirely contained within one program so I
don't understand what a "state" being "accessed" by one os thread means.
As I read it, the 'state' referred to is an IoState, meaning it is
safe for you to allocate one thread for each IoState instance. This
is safe because of the invariant that IoState instances share no
memory with each other.
--
Samuel A. Falvo II
Cliff Wells
2008-12-31 01:41:42 UTC
Permalink
Post by Guy Hulbert
Post by Rich Collins
You get one interpreter per thread. Each interpreter contains
separate coroutines (and state). AFAIK, the only way ATM to
communicate between the interpreters is to use sockets.
Thanks. That seems consistent with what I've been hearing. My problem
is that I don't understand exactly what "interpreter", "VM", and
"thread" mean. The documentation (see below) indicates that some of
these terms may not be a very precise way to talk about Io.
It seems to me that most people (myself included) tend to use
"interpreter" and "VM" interchangeably, even if this isn't exactly
correct. A VM and an interpreter can exist independently (Ruby has no
VM, LLVM has no interpreter), but most interpreted languages tie them
together closely enough that the distinction isn't important from the
outside. I'd say that the interpreter is what is responsible for
converting the textual representation of your source into something that
can be run on the VM. The VM is what actually runs the program and
handles things like memory management and interfacing with the OS.
Some people consider a VM to represent some sort of abstract CPU (like
the JVM or LLVM), but I don't think that's absolutely required (or maybe
it is, but that doesn't mean a CPU must be something with registers and
memory buses and pipelines, either).

"Thread" typically means "OS thread", that is, a light-weight (sort of),
preemptible process that shares memory with other threads within the
same process. Less frequently, "thread" is used to describe a
coroutine, which is a non-preemptible form of lightweight process that
runs within a single OS thread. OS threads will use multiple CPUs but
a coroutine will not (as it resides within a single OS thread). Also,
OS threads are managed (as the name implies) by the operating system
whereas coroutines are managed by the language (the VM).
Post by Guy Hulbert
Post by Rich Collins
Post by Steve Dekorte
Btw, IoVM's can only have one OS thread in them at a time so using a
VM per thread/process is the only way to get multi-core concurrency
for executing Io code.
Is this constraint (a VM per OS thread) fixed ?
The answer to this (below) appears to be "no", since the documentation
says "should" rather than "can't". Steve's recent comment is presumably
more authoritative than the documentation but there seems to be some
flexibility.
Post by Rich Collins
I'm really confused now. I shall look at the documentation (and code).
Here is the relevent section of the documentation.
http://iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html#Embedding-IoState
IoState
An IoState can be thought of as an instance of an Io "virtual
machine", although "virtual machine" is a less appropriate term
because it implies a particular type of implementation.
Multiple states
Io is multi-state, meaning that it is designed to support
multiple state instances within the same process. These
instances are isolated and share no memory so they can be safely
accessed simultaneously by different os threads, though a given
state should only be accessed by one os thread at a time.
I still don't understand "os threads". I understand threads to be
mini-processes but being entirely contained within one program so I
don't understand what a "state" being "accessed" by one os thread means.
OS threads share memory (within the same process anyway). This means
that any "state" (data structures, etc) that live within this shared
process can be read or written by any thread. The danger here is
two-fold: without sufficient locking, state can get confused by
simultaneous reads and writes by competing threads. With too much
locking, access to the state becomes serialized and your threaded
application performs no better than a single-threaded application (or
worse, can deadlock).

The easiest description of all the above would be:

OS process -> OS thread(s) -> coroutine(s)

where "->" can be read as "contains". Threads and coroutines naturally
share memory, processes do not (at least, not without external help from
the operating system).

Io complicates this picture slightly in that it uses OS threads, but
each thread is tied to a particular VM (IoState) and so they don't
*appear* to be able to access each other's data (from the Io side), even
though they exist within the same OS process and so *could* see each
others data (although probably not safely). I'll also note that I'm
speculating here quite a bit as I've not actually read most of the Io
source (nor would I expect to be much more enlightened if I did ;-)
Post by Guy Hulbert
This section of the documentation is under Embedding and discusses the C
implementation while my "understanding" above is from the Io side. A
diagram may help ... even if I have to read the code and draw it
myself ;-).
It's worth noting at this point that while it sounds like threads are a
huge advantage (preemptive, can run on multiple CPU's, etc), in practice
they have many disadvantages compared to coroutines. They are
difficult to use properly and can use much more memory. Also, heavy use
of threads can cause the CPU to be poorly utilized as they can
invalidate the CPU cache and cause pipelines to be flushed, among other
things, so the CPU ends up doing more housekeeping and less processing
of your application.

My personal belief is that a hybrid approach is best, with threads being
used for managing multiple async/coroutine-based processes.

Anyway, I hope the above wasn't badly misleading or full of outright
misinformation, but YMMV.

Regards,
Cliff
Guy Hulbert
2008-12-31 02:37:28 UTC
Permalink
Thanks for all the replies. I'm just replying to this bit.
Post by Cliff Wells
It seems to me that most people (myself included) tend to use
"interpreter" and "VM" interchangeably, even if this isn't exactly
correct.
Perl has a precise description of how the interpreter runs and what it
does. The interpreter is 'perl', the program. It reads your script.
Compiles it to an internal "byte code" and then runs the byte code on
the "virtual machine". The VM is a CPU emulation and the byte code
looks like machine language. I read through some of the perl1 source,
when it was made available a few years ago and everything is quite
explicit.

I know what threads are, generally. The Sun book I mentioned goes into
great detail about the implementations on Solaris, NT and OS/2 (the book
was written before 1995 and at that point, linux had no threads). So
the term "os threads" does not mean anything to me. Solaris
distinguishes "kernel threads" and "user threads" and the Sun book
covered both threaded programming and the specific implementations,
which are quite different.

It seems that Io is quite different from Perl. I do not disbelieve
anyone's explanations but it will still take me some time to understand
them. The key seems to be to understanding IoState.

My wife has an old copy of Knuth, some parts of which I have read ;-).
--
--gh
Cliff Wells
2008-12-31 03:13:42 UTC
Permalink
Post by Guy Hulbert
Thanks for all the replies. I'm just replying to this bit.
Post by Cliff Wells
It seems to me that most people (myself included) tend to use
"interpreter" and "VM" interchangeably, even if this isn't exactly
correct.
Perl has a precise description of how the interpreter runs and what it
does. The interpreter is 'perl', the program. It reads your script.
Compiles it to an internal "byte code" and then runs the byte code on
the "virtual machine". The VM is a CPU emulation and the byte code
looks like machine language. I read through some of the perl1 source,
when it was made available a few years ago and everything is quite
explicit.
This is the same as for Python, yet most people still lump them together
when discussing it from a high level (that is, any level where the
distinction is unimportant). For instance, the GIL is the "global
interpreter lock", when in reality, it's the VM (or in particular, it's
state) that is locked, not the interpreter. Perhaps because the VM is
also a bytecode interpreter (vs a source code interpreter) there may be
another layer of confusion.
Post by Guy Hulbert
My wife has an old copy of Knuth, some parts of which I have read ;-).
Well, you're one up on me then, I've only read the synopsis on Amazon =)

Regards,
Cliff
Jeremy Tregunna
2008-12-31 03:28:11 UTC
Permalink
Post by Guy Hulbert
Thanks for all the replies. I'm just replying to this bit.
Post by Cliff Wells
It seems to me that most people (myself included) tend to use
"interpreter" and "VM" interchangeably, even if this isn't exactly
correct.
Perl has a precise description of how the interpreter runs and what it
does. The interpreter is 'perl', the program. It reads your script.
Compiles it to an internal "byte code" and then runs the byte code on
the "virtual machine". The VM is a CPU emulation and the byte code
looks like machine language. I read through some of the perl1 source,
when it was made available a few years ago and everything is quite
explicit.
I know what threads are, generally. The Sun book I mentioned goes into
great detail about the implementations on Solaris, NT and OS/2 (the book
was written before 1995 and at that point, linux had no threads). So
the term "os threads" does not mean anything to me. Solaris
distinguishes "kernel threads" and "user threads" and the Sun book
covered both threaded programming and the specific implementations,
which are quite different.
It seems that Io is quite different from Perl. I do not disbelieve
anyone's explanations but it will still take me some time to
understand
them. The key seems to be to understanding IoState.
My wife has an old copy of Knuth, some parts of which I have read ;-).
Coroutines are discussed in the MIX/MMIX (for newer versions of TAoCP)
sections of TAoCP in detail. It's a very good read if you have a hard
time understanding coroutines. But I should note, once you make coros
aware of multiple processors, they are no longer coroutines without
big giant locks, and shared memory to store locals, which really
negate the benefits of coroutines by adding extra complexity and
overhead.

Regards,

Jeremy Tregunna
***@me.com
Steve Dekorte
2008-12-31 03:10:49 UTC
Permalink
Post by Guy Hulbert
I still don't understand "os threads". I understand threads to be
mini-processes but being entirely contained within one program so I
don't understand what a "state" being "accessed" by one os thread means.
The description could be better. "Accessing a state" means call a Io C
function with that state as an argument. All Io C functions pass the
state around in some form - usually via a IoObject struct which
contains a pointer to the state that owns it.
Jeremy Tregunna
2008-12-31 01:12:59 UTC
Permalink
It would be almost trivial to implement a shared memory model for
communicate between OS threads. I say "ALMOST" trivial, because it's
not quite, but it's not exactly hard.
Post by Rich Collins
You get one interpreter per thread. Each interpreter contains
separate coroutines (and state). AFAIK, the only way ATM to
communicate between the interpreters is to use sockets.
Post by Guy Hulbert
[snip]
That's the "*something*". However, you probably know this
(lighty is
async, iirc).
Yes, but async implies single-threaded. This means that a single
async
I don't believe this is correct in general. I'm not an expert though.
There is an interesting discussion of multi-processing models in the
Parrot documentation (they looked closely at Io when working out the
requirements).
[snip]
So why write an http server in the first place ?
Because it's an easy, portable way for an application to
communicate
with a traditional HTTP server or proxy. It's a protocol, nothing
more.
Ok.
[snip]
BTW, I'm having a difficult time deciding if we are agreeing or not ;-)
I'm not always arguing ... some of my questions are purely to
reduce my
own ignorance.
I like the asyncore/smtpd implementation in python. It seems to be the
right approach. It separates the protocol from the underlying details
very cleanly.
However, python won't use multiple cores without a fight ...
--gh
Regards,

Jeremy Tregunna
***@me.com
Guy Hulbert
2008-12-31 13:18:03 UTC
Permalink
Post by Guy Hulbert
Yes. But I haven't had time to even try building Io yet.
Updated and built it today.

I was surprised to be asked for a password by sudo during the make.

The SGML addon:
- runs sudo during 'make'
- modifies source files
- deletes source files on 'make clean'
- is not cleaned up by 'make uninstall'

A large number of libraries were reported missing (most of those are
probably due to not having header files installed).

I'm not sure whether SGML is an exceptional case as most addons were not
built because of the "missing" libraries.

The version number is still 200801xx (january). When does that get
changed?

If no-one is building debian packages yet, I might take a look at that.
--
--gh
Guy Hulbert
2009-01-01 14:53:14 UTC
Permalink
Steve.

I am now reading the Tutorial as I see the build is mostly done in Io.

Do you consider the SGML "problem" I noted a bug and what is the best
way for me to submit a fix? I could always fork the github project
and post things there.
Post by Guy Hulbert
Post by Guy Hulbert
Yes. But I haven't had time to even try building Io yet.
Updated and built it today.
I was surprised to be asked for a password by sudo during the make.
"... behaves differently from the rest ..."

[snip]
Post by Guy Hulbert
If no-one is building debian packages yet, I might take a look at that.
I will do this for my own use if nothing else.
--
--gh
Steve Dekorte
2009-01-01 16:08:58 UTC
Permalink
Post by Guy Hulbert
Do you consider the SGML "problem" I noted a bug and what is the best
way for me to submit a fix? I could always fork the github project
and post things there.
Iit would be nice if the SGML clib had packages for the popular
platforms, but as it doesn't I don't know of a better way to make it
easy for people to install it. I'm open to suggestions though.

- Steve
Guy Hulbert
2009-01-01 16:29:27 UTC
Permalink
Post by Steve Dekorte
Post by Guy Hulbert
Do you consider the SGML "problem" I noted a bug and what is the
best
Post by Guy Hulbert
way for me to submit a fix? I could always fork the github project
and post things there.
Iit would be nice if the SGML clib had packages for the popular
platforms, but as it doesn't I don't know of a better way to make it
easy for people to install it. I'm open to suggestions though.
The problem that I see is that it's calling 'sudo' unnecessarily.
Everything else built and installed without that (on debian /usr/local
is setgid and writable by the 'staff' group). I can fix that part -- at
least on debian it will be "fixed". I don't know if it would break rpm,
emerge, or ports though.

--- on suggestions

For debian, it's fairly easy. As long as there are no license
contentions, just package everything in separate packages as required.
The same should work for rpm-based distros (using yum) and emerge (and
ports, i think) builds everything from source anyway.

However, if you want something like ruby gems then external dependencies
do pose a problem. I haven't played enough with ruby to know anything
about what Debian does with that.

Debian policy may require that many of the dependent addons have
separate packages -- that's certainly how things are being packaged at
the moment; I'm just not sure how much separation is required by policy.
--
--gh
Guy Hulbert
2009-01-02 16:55:18 UTC
Permalink
Post by Guy Hulbert
The problem that I see is that it's calling 'sudo' unnecessarily.
Everything else built and installed without that (on debian /usr/local
is setgid and writable by the 'staff' group). I can fix that part -- at
least on debian it will be "fixed".
However, having run everything carefully, it seems the problem is this
line in the 'clean' target:

./_build/binaries/io_static$(BINARY_SUFFIX) build.io clean || true

which is what is compiling SGML ... unfortunately, I don't know Io well
enough (ok, i don't know io at all yet) to figure out _why_ it's doing
that.

Also.
make vm
make clean
git status

shows 4 files which are 64-bit linux executables which appear to have
been committed by accident at some point ... and

git commit -a -m "removed 64-bit linux executables"

will fix that.
--
--gh
Danya Alexeyevsky
2009-01-01 15:49:32 UTC
Permalink
Hi, Guy,

Jonas Eschenburg and I were the last maintainers of Debian packages
and looks like both of us bumped into having no time to continue
maintaining.

Actually, I feel like this would not require too much time unless you
really want to fit into all Debian policies and Jonas even started
searching "sponsors" (Debian term) for procedure of including package
in official distribution... That was the last I've heard of him. Also,
Jonas only released packages for versions of Io that Steve declared
stable or something like that (for which he either posted mail here or
updated version of tgz on the site).

The last version of our support scripts is here:
http://dendik.bpa.nu/io/iolanguage-debian (it's a darcs-pullable
repository).

BTW, problem with SGML is among those fixed by them. I'm afraid,
though, that many of patches will not apply.

Unfortunately, right now I'm still not able to create latest unstable
packages, so if you want to, go ahead! (I really wish I could return
to maintaining the package, as I learned a thing or two about how to
do it better).

Cheers,
-- Danya.
Danya Alexeyevsky
2009-01-01 15:53:49 UTC
Permalink
Sorry, typo, the address is: http://dendik.bpa.nu/io/debian/iolanguage-debian
Guy Hulbert
2009-01-01 16:02:03 UTC
Permalink
Post by Danya Alexeyevsky
http://dendik.bpa.nu/io/debian/iolanguage-debian
Great.

Thanks for this.

I volunteered to help out with perl so I'll be setting up a debian build
environment asap anyway. I'm not sure about anything "official" but I
will try to conform to debian policy as much as possible.
--
--gh
Guy Hulbert
2009-01-01 16:15:55 UTC
Permalink
Post by Danya Alexeyevsky
http://dendik.bpa.nu/io/iolanguage-debian (it's a darcs-pullable
repository).
This seems to be converting to git nicely[1] ... I'll throw it up on
github once I get it working. May take a few days (weeks if I get too
busy ;-).

[1] after installing ruby, darcs and pulling
http://git.sanityinc.com/?p=darcs-to-git.git
--
--gh
k***@ymail.com
2008-12-24 08:09:21 UTC
Permalink
1- I am not saying Io (or io?) is not stable (or is) because I have
not used it extensively. I say Io has not an ecosystem yet - I do not
know what should be done but I think there should be a plan (for
example 1- spotting important points at current era : concurrency and
distribution must be considered more than before and ... 2- having a
(flexible) philosophy for doing things (not like the one for Lisp) 3-
having a plan (ide, lib, web (rails!), ...).

2- You are right! Io does not play well with search engines. That
could be a problem. Maybe having a custom of tagging Io resources in
format of Io-somthing (Io-language, Io-ide, Io-*, ...) can help (I do
not know).
William Tanksley, Jr
2008-12-24 08:18:35 UTC
Permalink
Post by k***@ymail.com
2- You are right! Io does not play well with search engines. That
could be a problem. Maybe having a custom of tagging Io resources in
format of Io-somthing (Io-language, Io-ide, Io-*, ...) can help (I do
not know).
Io is the 5th result when I search Google and Yahoo. It's the first
tech result (in fact, it's the first that's not a moon).

I don't really see a need to work at improving this except by making
Io more popular and linked-to.

Brainstorms, anyone?

Maybe the ultimate library, free of legacy considerations -- like
Factor is doing (for example, with Unicode)? Smalltalk is REALLY cool
and they knew what they were doing, but surely prototypes give us
_something_ they didn't have... right?

-Wm
Samuel A. Falvo II
2008-12-24 08:27:25 UTC
Permalink
On Wed, Dec 24, 2008 at 12:18 AM, William Tanksley, Jr
Post by William Tanksley, Jr
Post by k***@ymail.com
2- You are right! Io does not play well with search engines. That
could be a problem. Maybe having a custom of tagging Io resources in
format of Io-somthing (Io-language, Io-ide, Io-*, ...) can help (I do
not know).
Io is the 5th result when I search Google and Yahoo. It's the first
tech result (in fact, it's the first that's not a moon).
Billy, beware that most search engines have different collation
algorithms depending on the user's locale. Your results are accurate
for USA users, but may not apply for users in other countries.

For example, Italian literature makes routine use of the word "Io",
which is the pronoun "I" in English. Attempting to search for "Io
language" on www.google.it *FROM ITALY* will yield a plethora of
irrelevant results. (Note: attempting to search for it from the USA
will still give a USA-optimized search result, although the rendered
language will still be in Italian! Remember: localization and
internationalization are different concepts!)
Post by William Tanksley, Jr
I don't really see a need to work at improving this except by making
Io more popular and linked-to.
Ultimately, this is the best solution, I think. Still, have *some*
sympathy for non-USA speakers.
--
Samuel A. Falvo II
k***@ymail.com
2008-12-24 21:24:59 UTC
Permalink
Steve,

I have came along with this discussion on LTU today. I do not know if
you have seen it before but it worth a look; here:
http://lambda-the-ultimate.org/node/2596

Regards
Jeremy Tregunna
2008-12-24 04:25:33 UTC
Permalink
Being a little less confrontational...
Post by k***@ymail.com
One of most interesting things to me was io! Yet it was somehow risky
to be used in product-environment. I was really in some levels of love
with io and said to myself: "It will be a stable plateform in at most
2 years from now" and I went on my daily job and I have lost io.
When there is a small group of regular contributors, all with day jobs
and other projects; finding time to develop a programming language
more than incrementally little patch here, little patch there, is
difficult. It's especially difficult, when one of those people (namely
myself) decided to stop contributing to the project for various
reasons. I've found more time to touch up pieces of Io that I want to,
but major systems that I want to tackle are not likely to receive
attention from me anyway, I'll instead make these changes in the
alternate Io implementation that I'm currently working on.

If there were more than a fading interest in Io by those that pass us
by, there would be more hands potentially assisting in development,
which would do things like clean up the APIs, fix things like Numbers,
implement new language subsystems that may offer benefit, and really I
can keep on going. Having really only 4 or 5 people contribute on a
regular basis, each to their own little portions, aside from really
only 2 people I know of, makes it hard to progress forwards quickly.
Post by k***@ymail.com
Recently I was playing with Clojure and suddenly I have remembered io!
I came back and almost nothing has changed much in 3 years!
Having used Io since 2002, a lot has changed, even in the last 3
years. The collections API has completely changed, for example. Most
of the development in that time however, has been in the clean up of
code, and developing a set of useful addons.
Post by k***@ymail.com
What is the plan for io? I totally agree that io is more powerful than
both Ruby and Lisp; but I want to use it!
Note: And even you have not enough resource to work on io (which is a
piece of pure beauty thanks to you) at least change the name; it will
help so much! For example metaio! Because it is already metaio!
A name change is not really needed.

Regards,

Jeremy Tregunna
***@me.com
k***@ymail.com
2008-12-24 08:32:38 UTC
Permalink
I am not in position of put it on Io folks or like that. And I am not
that smart to claim things are right/wrong about Io. I am just
interested in Io (More than Ruby which I have used a little, more than
Python which I was always resistant to use it dnt-know why, more that
Perl which I am afraid of, and more that PHP which I always have hated
yet it is doing it's job (but will have problems according to changes
in hardware and the rest)).

I am looking forward to see your Io implementation! :)

And if there was a good integration with web servers Io could be used
more easily than now. And there would be more interests and more
contributors to Io. (Do not count me! I am not as good as I pretend to
be in programming!).

I will look into the new Io more deeply.

Regrds
Nick Guenther
2008-12-24 04:31:58 UTC
Permalink
What does the name have to do with it..? "Io" is elegant, like the language.
Post by k***@ymail.com
It was around 2005 when I started to use C# 2.0; the Ruby trend was
coming up and I started to learn it! In fact I started to learn how a
language can help or harm. I have studied Haskell, F#, Lisp and even
JavaScript (Yes! I have started to understand it; yet I was using it a
long time before that)! There were other things too like Q (Qi is
another thing) and Python.
One of most interesting things to me was io! Yet it was somehow risky
to be used in product-environment. I was really in some levels of love
with io and said to myself: "It will be a stable plateform in at most
2 years from now" and I went on my daily job and I have lost io.
Recently I was playing with Clojure and suddenly I have remembered io!
I came back and almost nothing has changed much in 3 years!
What is the plan for io? I totally agree that io is more powerful than
both Ruby and Lisp; but I want to use it!
Note: And even you have not enough resource to work on io (which is a
piece of pure beauty thanks to you) at least change the name; it will
help so much! For example metaio! Because it is already metaio!
Cheers!
Steve Dekorte
2008-12-24 22:35:34 UTC
Permalink
Post by k***@ymail.com
What is the plan for io?
The basic plan is continual refinement.

These are the things I feel we need before Io reaches my standard for
1.x:

- clean up of the APIs
- Sequence, File, Socket, List, etc
- clean up and improvement the addons
- separating libevent and URL from Socket, etc
- finish out the docs

How folks can help:

- contribute to the above
- post your API cleanup suggestions
- help fill in the docs
- take ownership of or write a new addon
- add your favorite features
- write unit tests
- test on different platforms

How to get started:

- checkout Io from github
- push your changes to your github account and notify me

Cheers,
- Steve
Cliff Wells
2008-12-25 06:49:06 UTC
Permalink
Post by Steve Dekorte
- checkout Io from github
- push your changes to your github account and notify me
I'll vouch that this process works. Not only that, but github converted
me from Subversion in short order =)

Cliff
Mike
2008-12-26 23:27:20 UTC
Permalink
Posting to gmane seems to send my message to mars, so let's try again...

I've been using Io on and off for years, and the language I've been
working on, Impulse, has borrowed heavily from it. The things that
I've noticed is that it has bloated a bit. Take Sequence for example:

Io> Sequence slotNames size
==> 182

With methods such as:

alignRight
asHex
x
red
cos

These don't have any direct relation to a Sequence, they're just
convenience methods. I'd suggest moving these to other protos.

alignRight - move to "format" method or Format object
asHex - I'm not even sure what this does
x - Move to Vector, along with y, z, setX, setY, etc.
red - Move to Color, along with blue, green
cos - Move to Vector, along with sin, abs, atan, etc.
etc., etc.

I believe that no vector math functions should be in Sequence. That's
what vector is for. Btw, what does "Number years" do?

My $.02.
Mike
Post by Steve Dekorte
Post by k***@ymail.com
What is the plan for io?
The basic plan is continual refinement.
These are the things I feel we need before Io reaches my standard for
- clean up of the APIs
- Sequence, File, Socket, List, etc
- clean up and improvement the addons
- separating libevent and URL from Socket, etc
- finish out the docs
- contribute to the above
- post your API cleanup suggestions
- help fill in the docs
- take ownership of or write a new addon
- add your favorite features
- write unit tests
- test on different platforms
- checkout Io from github
- push your changes to your github account and notify me
Cheers,
- Steve
Marc 'BlackJack Rintsch
2008-12-27 00:25:24 UTC
Permalink
Post by Mike
These don't have any direct relation to a Sequence, they're just
convenience methods. I'd suggest moving these to other protos.
[
]
asHex - I'm not even sure what this does
Converts eacht (byte) value into its two digit hexadecimal
representation.

Io> "\0a 0" asHex
==> 00612030
Post by Mike
[
] Btw, what does "Number years" do?
Creates a `Duration` of the given years.

Io> 10 years
==> 10 years 00 days 00:00:0.000000
Io> 10 years type
==> Duration
Io> Date now
==> 2008-12-27 01:24:33 CET
Io> Date now + 10 years
==> 2018-12-25 01:24:41 CET

Ciao,
Marc 'BlackJack' Rintsch
--
“Wherever there is modularity there is the potential
for misunderstanding: Hiding information implies
a need to check communication.”
-- Alan J. Perlis
Mike
2008-12-27 06:36:55 UTC
Permalink
Post by Marc 'BlackJack Rintsch
Post by Mike
These don't have any direct relation to a Sequence, they're just
convenience methods. I'd suggest moving these to other protos.
[
]
asHex - I'm not even sure what this does
Converts eacht (byte) value into its two digit hexadecimal
representation.
Io> "\0a 0" asHex
==> 00612030
I see. Maybe it just needs a more descriptive same, such as
"asHexSequence". "15" asHex to me would return 0xF, 15 in hex. The
thing with String is that it could be considered as a single value or
as a sequence, so it would be nice to have more descriptive methods in
this case.
Post by Marc 'BlackJack Rintsch
Post by Mike
[
] Btw, what does "Number years" do?
Creates a `Duration` of the given years.
Io> 10 years
==> 10 years 00 days 00:00:0.000000
Io> 10 years type
==> Duration
Io> Date now
==> 2008-12-27 01:24:33 CET
Io> Date now + 10 years
==> 2018-12-25 01:24:41 CET
Hmm. Sure it's convenient, but years is not a function of number and
pollutes Number's namespace. "Duration years(5)" is a little longer,
but it's more descriptive and doesn't pollute Number.

Another option would be to create a "unit" evaluator, which shims in
an object above Number that recognizes years, days, MB, KB, meters,
seconds, etc.:

time = unit(10 years + 5 days)
speed = unit(2 meters / second)
Post by Marc 'BlackJack Rintsch
Ciao,
Marc 'BlackJack' Rintsch
--
“Wherever there is modularity there is the potential
for misunderstanding: Hiding information implies
a need to check communication.”
-- Alan J. Perlis
Regards,
Mike
Samuel A. Falvo II
2008-12-27 07:23:10 UTC
Permalink
Post by Mike
Hmm. Sure it's convenient, but years is not a function of number and
pollutes Number's namespace.
It takes an non-complex number, and returns a corresponding duration.
Given the same input, it returns the same value. Across the entire
domain of the function, no results will ever repeat. That fully
conforms to the definition of a function in every mathematics book
I've ever read.

I think what you meant to say is that the years method is "incoherent"
-- e.g., the Number "class" (insofar as it is a class at all) is
attempting to do too much.

A better approach, in my opinion, would be to define a prototype which
implements "years" as currently defined with Number, and then
reference it in a subtype if you need it. In other words, "traits" as
used in Smalltalk. E.g.:

Duration := Object clone do(
years := method( . . . )
/* . . . */
)


Timespan := Number clone do(
appendProto(Duration)
/* . . . */
)
--
Samuel A. Falvo II
Jeremy Tregunna
2008-12-27 15:54:29 UTC
Permalink
Post by Samuel A. Falvo II
A better approach, in my opinion, would be to define a prototype which
implements "years" as currently defined with Number, and then
reference it in a subtype if you need it. In other words, "traits" as
Duration := Object clone do(
years := method( . . . )
/* . . . */
)
Timespan := Number clone do(
appendProto(Duration)
/* . . . */
)
This unfortunately will not work without a hook into the lexer to tell
the parsing subsystem that the next time it comes upon a number
literal token, make it a Timespan and not a Number. You'd have to mix
in your intermediate object which defines those methods into Number's
protos, then remove it when you're done (optionally).
Post by Samuel A. Falvo II
Samuel A. Falvo II
Regards,

Jeremy Tregunna
***@me.com
Samuel A. Falvo II
2008-12-27 17:34:19 UTC
Permalink
Post by Jeremy Tregunna
Post by Samuel A. Falvo II
Timespan := Number clone do(
appendProto(Duration)
/* . . . */
)
This unfortunately will not work without a hook into the lexer to tell
the parsing subsystem that the next time it comes upon a number
literal token, make it a Timespan and not a Number.
Good point -- I forgot about that.

Perhaps Io needs a reader-macro system? :)
--
Samuel A. Falvo II
Jeremy Tregunna
2008-12-27 17:36:54 UTC
Permalink
Or we could just allow become() on primitive types again. So you could
do:

5 become(Timespan) years

But apparently that was bad because you could do things like: 42
become("forty-two") which apparently is confusing :)
Post by Samuel A. Falvo II
Post by Jeremy Tregunna
Post by Samuel A. Falvo II
Timespan := Number clone do(
appendProto(Duration)
/* . . . */
)
This unfortunately will not work without a hook into the lexer to tell
the parsing subsystem that the next time it comes upon a number
literal token, make it a Timespan and not a Number.
Good point -- I forgot about that.
Perhaps Io needs a reader-macro system? :)
--
Samuel A. Falvo II
------------------------------------
Yahoo! Groups Links
Regards,

Jeremy Tregunna
***@me.com
Jeremy Tregunna
2008-12-27 17:37:57 UTC
Permalink
Ooops, I should note that if you become another object, you will
especially want to (on numbers -10 ~ +250) become(Number) after you're
done with it, otherwise it stays a Timespan which may not be what you
want.
Post by Jeremy Tregunna
Or we could just allow become() on primitive types again. So you could
5 become(Timespan) years
But apparently that was bad because you could do things like: 42
become("forty-two") which apparently is confusing :)
Post by Samuel A. Falvo II
Post by Jeremy Tregunna
Post by Samuel A. Falvo II
Timespan := Number clone do(
appendProto(Duration)
/* . . . */
)
This unfortunately will not work without a hook into the lexer to tell
the parsing subsystem that the next time it comes upon a number
literal token, make it a Timespan and not a Number.
Good point -- I forgot about that.
Perhaps Io needs a reader-macro system? :)
--
Samuel A. Falvo II
------------------------------------
Yahoo! Groups Links
Regards,
Jeremy Tregunna
------------------------------------
Yahoo! Groups Links
Regards,

Jeremy Tregunna
***@me.com
Cliff Wells
2008-12-27 07:41:42 UTC
Permalink
Post by Mike
Hmm. Sure it's convenient, but years is not a function of number and
pollutes Number's namespace. "Duration years(5)" is a little longer,
but it's more descriptive and doesn't pollute Number.
I agree. I've noticed that in a few places the standard library seems a
bit unfocused. Sometimes too many convenience methods, sometimes not
enough core methods.

Perhaps more accurately, Io feels like it actually lacks a standard
library. That is, a place where common stuff is available, but not
needlessly loaded onto base objects unless explicitly asked for.

Regards,
Cliff
Friedrich
2008-12-27 09:45:46 UTC
Permalink
Post by Cliff Wells
Post by Mike
Hmm. Sure it's convenient, but years is not a function of number and
pollutes Number's namespace. "Duration years(5)" is a little longer,
but it's more descriptive and doesn't pollute Number.
I agree. I've noticed that in a few places the standard library seems a
bit unfocused. Sometimes too many convenience methods, sometimes not
enough core methods.
Perhaps more accurately, Io feels like it actually lacks a standard
library. That is, a place where common stuff is available, but not
needlessly loaded onto base objects unless explicitly asked for.
I disagree about that, as I wrote before. It absolutly depends on the
"area" your' working in. If you work with Time this is especiall a
mine field...

Regards
Friedrich
--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
Cliff Wells
2008-12-27 23:28:25 UTC
Permalink
Post by Friedrich
Post by Cliff Wells
Post by Mike
Hmm. Sure it's convenient, but years is not a function of number and
pollutes Number's namespace. "Duration years(5)" is a little longer,
but it's more descriptive and doesn't pollute Number.
I agree. I've noticed that in a few places the standard library seems a
bit unfocused. Sometimes too many convenience methods, sometimes not
enough core methods.
Perhaps more accurately, Io feels like it actually lacks a standard
library. That is, a place where common stuff is available, but not
needlessly loaded onto base objects unless explicitly asked for.
I disagree about that, as I wrote before. It absolutly depends on the
"area" your' working in. If you work with Time this is especiall a
mine field...
My point is that Time should be a separate prototype from Number and not
present unless explicitly asked for. If I have a number representing
temperature, why would I want to perform time arithmetic on it? For
that matter, why not also add Celsius, Fahrenheit and Kelvin conversions
to all Numbers as well? This is what I mean by "unfocused". A Number
should be just that, without implying any particular problem domain that
a Number might be used in (which is almost every problem domain in
existence).

Regards,
Cliff
Steve Dekorte
2008-12-28 11:31:37 UTC
Permalink
I agree with the general points made about removing the years, days,
etc methods from Number and having a Vector proto to hold Sequence's
vector methods. I'll try to make those changes and welcome help in
that area.

Also, thanks to Jer for posting his standard library implementation.
It looks like a good direction.

- Steve
Jeremy Tregunna
2008-12-27 15:55:27 UTC
Permalink
I had started working on a standard library back in 2006, I got a fair
bit done, but still nowhere near complete. Written entirely in Io as a
prototype, I recently put it up: http://www.cariboulanguage.org/files/stdlib.tar.gz
Post by Cliff Wells
Post by Mike
Hmm. Sure it's convenient, but years is not a function of number and
pollutes Number's namespace. "Duration years(5)" is a little longer,
but it's more descriptive and doesn't pollute Number.
I agree. I've noticed that in a few places the standard library seems a
bit unfocused. Sometimes too many convenience methods, sometimes not
enough core methods.
Perhaps more accurately, Io feels like it actually lacks a standard
library. That is, a place where common stuff is available, but not
needlessly loaded onto base objects unless explicitly asked for.
Regards,
Cliff
------------------------------------
Yahoo! Groups Links
Regards,

Jeremy Tregunna
***@me.com
Mike
2008-12-30 04:49:58 UTC
Permalink
Hi Jeremy, do you mind putting up the file in a different archive
format? I couldn't open stdlib.tar.gz in Windows or Linux. .zip or .bz2?

Mike
Post by Jeremy Tregunna
I had started working on a standard library back in 2006, I got a fair
bit done, but still nowhere near complete. Written entirely in Io as a
http://www.cariboulanguage.org/files/stdlib.tar.gz
Post by Jeremy Tregunna
Post by Cliff Wells
Post by Mike
Hmm. Sure it's convenient, but years is not a function of number and
pollutes Number's namespace. "Duration years(5)" is a little longer,
but it's more descriptive and doesn't pollute Number.
I agree. I've noticed that in a few places the standard library seems a
bit unfocused. Sometimes too many convenience methods, sometimes not
enough core methods.
Perhaps more accurately, Io feels like it actually lacks a standard
library. That is, a place where common stuff is available, but not
needlessly loaded onto base objects unless explicitly asked for.
Regards,
Cliff
------------------------------------
Yahoo! Groups Links
Regards,
Jeremy Tregunna
Scott Solmonson
2008-12-30 05:46:27 UTC
Permalink
You must have got a bad dload- it's a well formatted tgz:

incitatus:~ scosol$ cd Desktop/
incitatus:Desktop scosol$ tar xvfz ./stdlib.tar.gz
stdlib/
stdlib/Array.io
stdlib/BigNumber.io
stdlib/Character.io

-SS
Post by Mike
Hi Jeremy, do you mind putting up the file in a different archive
format? I couldn't open stdlib.tar.gz in Windows or Linux. .zip or .bz2?
Mike
Post by Jeremy Tregunna
I had started working on a standard library back in 2006, I got a fair
bit done, but still nowhere near complete. Written entirely in Io as a
http://www.cariboulanguage.org/files/stdlib.tar.gz
Post by Jeremy Tregunna
Post by Cliff Wells
Post by Mike
Hmm. Sure it's convenient, but years is not a function of number and
pollutes Number's namespace. "Duration years(5)" is a little longer,
but it's more descriptive and doesn't pollute Number.
I agree. I've noticed that in a few places the standard library seems a
bit unfocused. Sometimes too many convenience methods, sometimes not
enough core methods.
Perhaps more accurately, Io feels like it actually lacks a standard
library. That is, a place where common stuff is available, but not
needlessly loaded onto base objects unless explicitly asked for.
Regards,
Cliff
------------------------------------
Yahoo! Groups Links
Regards,
Jeremy Tregunna
------------------------------------
Yahoo! Groups Links
Samuel A. Falvo II
2008-12-30 07:31:42 UTC
Permalink
Post by Mike
Hi Jeremy, do you mind putting up the file in a different archive
format? I couldn't open stdlib.tar.gz in Windows or Linux. .zip or .bz2?
winzip will also decompress and dearchive .tar.gz files.
--
Samuel A. Falvo II
Danya Alexeyevsky
2008-12-30 12:57:13 UTC
Permalink
Looks like Jeremy gzipped it one time too many.

$ gunzip stdlib.tar.gz
$ file stdlib.tar
stdlib.tar: gzip compressed data, was "stdlib.tar", from Unix, last
modified: Sat Dec 27 18:58:43 2008, max compression
$ mv stdlib.tar{,.gz}
$ tar tzf stdlib.tar.gz
stdlib/
stdlib/Array.io
stdlib/BigNumber.io
...
Post by Mike
Hi Jeremy, do you mind putting up the file in a different archive
format? I couldn't open stdlib.tar.gz in Windows or Linux. .zip or .bz2?
Mike
Jeremy Tregunna
2008-12-30 14:07:09 UTC
Permalink
I in fact didn't. Note:

% gzip -d stdlib.tar.gz
% file stdlib.tar
stdlib.tar: POSIX tar archive (GNU)
% gzip -9 stdlib.tar
% file stdlib.tar.gz
stdlib.tar.gz: gzip compressed data, was "stdlib.tar", from Unix, last
modified: Sat Dec 27 10:59:50 2008, max compression

But I did recompress it in the hopes that maybe that will help. If it
is still a gzip'd tgz, then let me know and I'll check my nginx
configuration.
Post by Danya Alexeyevsky
Looks like Jeremy gzipped it one time too many.
$ gunzip stdlib.tar.gz
$ file stdlib.tar
stdlib.tar: gzip compressed data, was "stdlib.tar", from Unix, last
modified: Sat Dec 27 18:58:43 2008, max compression
$ mv stdlib.tar{,.gz}
$ tar tzf stdlib.tar.gz
stdlib/
stdlib/Array.io
stdlib/BigNumber.io
...
Post by Mike
Hi Jeremy, do you mind putting up the file in a different archive
format? I couldn't open stdlib.tar.gz in Windows or Linux. .zip or .bz2?
Mike
------------------------------------
Yahoo! Groups Links
Regards,

Jeremy Tregunna
***@me.com
Danya Alexeyevsky
2008-12-30 14:22:53 UTC
Permalink
Ah, it's probably http compression shooting out in some strange way
(in my case, a Mozilla bug then).
Post by Jeremy Tregunna
% gzip -d stdlib.tar.gz
% file stdlib.tar
stdlib.tar: POSIX tar archive (GNU)
% gzip -9 stdlib.tar
% file stdlib.tar.gz
stdlib.tar.gz: gzip compressed data, was "stdlib.tar", from Unix, last
modified: Sat Dec 27 10:59:50 2008, max compression
But I did recompress it in the hopes that maybe that will help. If it
is still a gzip'd tgz, then let me know and I'll check my nginx
configuration.
Mike
2009-01-02 20:53:35 UTC
Permalink
I got it :) A few questions...

Float is a type of Integer?

These days, I see String more as a root object or "character related"
than inheriting from Array, Collection, etc. String must handle
encodings, multi-byte characters, etc. and may not be linear. I could
see them inheriting from a more generic Enumerable or something like
that. Just my 2c.

How is a Dictionary sorted? When you iterate over a dictionary, the
keys are not in any order, right?

Mike Austin
Post by Jeremy Tregunna
% gzip -d stdlib.tar.gz
% file stdlib.tar
stdlib.tar: POSIX tar archive (GNU)
% gzip -9 stdlib.tar
% file stdlib.tar.gz
stdlib.tar.gz: gzip compressed data, was "stdlib.tar", from Unix, last
modified: Sat Dec 27 10:59:50 2008, max compression
But I did recompress it in the hopes that maybe that will help. If it
is still a gzip'd tgz, then let me know and I'll check my nginx
configuration.
Post by Danya Alexeyevsky
Looks like Jeremy gzipped it one time too many.
$ gunzip stdlib.tar.gz
$ file stdlib.tar
stdlib.tar: gzip compressed data, was "stdlib.tar", from Unix, last
modified: Sat Dec 27 18:58:43 2008, max compression
$ mv stdlib.tar{,.gz}
$ tar tzf stdlib.tar.gz
stdlib/
stdlib/Array.io
stdlib/BigNumber.io
...
Post by Mike
Hi Jeremy, do you mind putting up the file in a different archive
format? I couldn't open stdlib.tar.gz in Windows or Linux. .zip or .bz2?
Mike
------------------------------------
Yahoo! Groups Links
Regards,
Jeremy Tregunna
Steve Dekorte
2009-01-03 01:12:31 UTC
Permalink
Post by Mike
How is a Dictionary sorted?
It's not.
Post by Mike
When you iterate over a dictionary, the
keys are not in any order, right?
Right.

- Steve
Mike
2009-01-03 21:22:46 UTC
Permalink
Post by Steve Dekorte
Post by Mike
How is a Dictionary sorted?
It's not.
Post by Mike
When you iterate over a dictionary, the
keys are not in any order, right?
Right.
- Steve
I was referring to Jeremy's proto hierarchy. He has Dictionary as a
sorted, ordered collection. I'm confused :)

Mike
Jeremy Tregunna
2009-01-03 22:52:39 UTC
Permalink
Post by Mike
Post by Steve Dekorte
Post by Mike
How is a Dictionary sorted?
It's not.
Post by Mike
When you iterate over a dictionary, the
keys are not in any order, right?
Right.
- Steve
I was referring to Jeremy's proto hierarchy. He has Dictionary as a
sorted, ordered collection. I'm confused :)
It's not sorted exactly. It's a red black tree with in-order tree
traversal.
Regards,

Jeremy Tregunna
***@me.com
William Tanksley, Jr
2009-01-03 23:18:07 UTC
Permalink
Post by Mike
These days, I see String more as a root object or "character related"
than inheriting from Array, Collection, etc. String must handle
encodings, multi-byte characters, etc. and may not be linear. I could
see them inheriting from a more generic Enumerable or something like
that. Just my 2c.
It's a good idea to not support random access to characters in
strings, except when treating them as arrays. Thus, Array is a very
poor model for the behavior of a string.

You want quick joins and appends, arbitrary sequence searches,
iteration over graphemes, and similar things. You don't often want to
index arbitrarily; when you do, it's probably best to provide a means
to encode the string into some explicit representation (UTF-8, ASCII,
or whatever) so that you can be alerted if something is wrong about
accessing that string in that way.
Post by Mike
Mike Austin
-Wm
Steve Dekorte
2009-01-04 04:21:15 UTC
Permalink
Post by William Tanksley, Jr
You want quick joins and appends, arbitrary sequence searches,
iteration over graphemes, and similar things. You don't often want to
index arbitrarily; when you do, it's probably best to provide a means
to encode the string into some explicit representation (UTF-8, ASCII,
or whatever) so that you can be alerted if something is wrong about
accessing that string in that way.
While there are disadvantages, some of the advantages of strings as
arrays are:
- it simplifies the implementation of mutation operations
- one can unify the implementation of strings, vectors and arrays
- operations on arrays can often be SIMD accelerated
- array operations often have better cache behavior
William Tanksley, Jr
2009-01-04 04:48:21 UTC
Permalink
Post by Steve Dekorte
Post by William Tanksley, Jr
You want quick joins and appends, arbitrary sequence searches,
iteration over graphemes, and similar things. You don't often want to
index arbitrarily; when you do, it's probably best to provide a means
to encode the string into some explicit representation (UTF-8, ASCII,
or whatever) so that you can be alerted if something is wrong about
accessing that string in that way.
While there are disadvantages, some of the advantages of strings as
- it simplifies the implementation of mutation operations
It only simplifies array-type mutation operations, which are NOT the
most common string mutations. If you want string-type mutation
operations, like arbitrary replace, concatenate, delete, and insert,
other structures (for example, Ropes http://ahmadsoft.org/ropes/) are
better.
Post by Steve Dekorte
- one can unify the implementation of strings, vectors and arrays
This is not an advantage.
Post by Steve Dekorte
- operations on arrays can often be SIMD accelerated
True. But only certain types of operations; and many string
manipulations cannot.
Post by Steve Dekorte
- array operations often have better cache behavior
This IS important.

Of course, all this assumes mutability. If you want immutable strings,
using arrays makes no sense at all. If you're using Unicode, ditto
(graphemes are variable width due to combining characters).

-Wm
Steve Dekorte
2009-01-04 04:59:23 UTC
Permalink
Post by William Tanksley, Jr
Of course, all this assumes mutability. If you want immutable strings,
using arrays makes no sense at all. If you're using Unicode, ditto
(graphemes are variable width due to combining characters).
UTF can be encoded in fixed width encodings such as UCS2 and USC4.
Friedrich
2008-12-27 09:44:11 UTC
Permalink
Post by Marc 'BlackJack Rintsch
Post by Mike
These don't have any direct relation to a Sequence, they're just
convenience methods. I'd suggest moving these to other protos.
[~]
asHex - I'm not even sure what this does
Converts eacht (byte) value into its two digit hexadecimal
representation.
Io> "\0a 0" asHex
==> 00612030
Post by Mike
[~] Btw, what does "Number years" do?
Creates a `Duration` of the given years.
Io> 10 years
==> 10 years 00 days 00:00:0.000000
Io> 10 years type
==> Duration
Io> Date now
==> 2008-12-27 01:24:33 CET
Io> Date now + 10 years
==> 2018-12-25 01:24:41 CET
Sorry that is done in Ruby also if you load active_support you get
extension to numbers and in fact I can not see any reason to not
extend Numbers for different areas.

today = Date.today
=> Sat, 27 Dec 2008
irb(main):006:0> today + 10.years
=> Thu, 27 Dec 2018
irb(main):007:0>

However I guess you underestimate how difficult it really is to write
a good standard library. Java tries for more than 10 years, and has
collected quite some garbage. :NET is similar and how long it took to
get Smalltalk libraries ... Well I guess you got the idea. The
especially nice thing in Ruby and Io is that classes are never
closed. Of course this can be abused also, but not having it means not
a better choice. At least not for me.

Regards
Friedrich
--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
Kevin Clark
2008-12-27 16:57:02 UTC
Permalink
On Sat, Dec 27, 2008 at 1:44 AM, Friedrich
Post by Friedrich
Sorry that is done in Ruby also if you load active_support you get
extension to numbers and in fact I can not see any reason to not
extend Numbers for different areas.
That's done in _Rails_ also, if you load active_support, which is an
external library. In general, Rubyists (if not Rails people) that I've
talked to would be happy to reduce the number of methods in built in
classes.

But that's Ruby, this is Io, and I don't feel the need to make them
the same :) I do, however, think that separating conceptually
different actions into different namespaces could help reduce
cognitive load when you're trying to figure out how something works.
--
Kevin Clark
http://glu.ttono.us
embro_beemas
2008-12-27 22:13:46 UTC
Permalink
Nono, it was right the first time. ActiveSupport is a Ruby library which adds, among other
things, Numeric extensions, such as 10.bytes, 5.days, etc.

Yes, it's a Rails dependency, but it's frequently used outside of Rails. And yes, it's
bloated, but you can cherry pick what to include and mix in if you really want.
Post by Kevin Clark
On Sat, Dec 27, 2008 at 1:44 AM, Friedrich
Post by Friedrich
Sorry that is done in Ruby also if you load active_support you get
extension to numbers and in fact I can not see any reason to not
extend Numbers for different areas.
That's done in _Rails_ also, if you load active_support, which is an
external library. In general, Rubyists (if not Rails people) that I've
talked to would be happy to reduce the number of methods in built in
classes.
But that's Ruby, this is Io, and I don't feel the need to make them
the same :) I do, however, think that separating conceptually
different actions into different namespaces could help reduce
cognitive load when you're trying to figure out how something works.
--
Kevin Clark
http://glu.ttono.us
Kevin Clark
2008-12-27 04:35:23 UTC
Permalink
Yeah, I found the sheer amount of stuff on Sequence a little daunting.
I think right now it's trying to be a buffer, a vector, a string, and
a bunch of other things all wrapped into one. I think unification of
concepts is a good thing, but in this case I think we need a few new
prototypes. asSOMEDATATYPE seems like a code smell which indicates a
new proto, in some cases.
Post by Mike
Posting to gmane seems to send my message to mars, so let's try again...
I've been using Io on and off for years, and the language I've been
working on, Impulse, has borrowed heavily from it. The things that
Io> Sequence slotNames size
==> 182
alignRight
asHex
x
red
cos
These don't have any direct relation to a Sequence, they're just
convenience methods. I'd suggest moving these to other protos.
alignRight - move to "format" method or Format object
asHex - I'm not even sure what this does
x - Move to Vector, along with y, z, setX, setY, etc.
red - Move to Color, along with blue, green
cos - Move to Vector, along with sin, abs, atan, etc.
etc., etc.
I believe that no vector math functions should be in Sequence. That's
what vector is for. Btw, what does "Number years" do?
My $.02.
Mike
Post by Steve Dekorte
Post by k***@ymail.com
What is the plan for io?
The basic plan is continual refinement.
These are the things I feel we need before Io reaches my standard for
- clean up of the APIs
- Sequence, File, Socket, List, etc
- clean up and improvement the addons
- separating libevent and URL from Socket, etc
- finish out the docs
- contribute to the above
- post your API cleanup suggestions
- help fill in the docs
- take ownership of or write a new addon
- add your favorite features
- write unit tests
- test on different platforms
- checkout Io from github
- push your changes to your github account and notify me
Cheers,
- Steve
------------------------------------
Yahoo! Groups Links
--
Kevin Clark
http://glu.ttono.us
Continue reading on narkive:
Loading...