Problems during installation

On Fri, 2006-10-27 at 16:20 -0700, Steve Dekorte wrote:
> 
> On Oct 27, 2006, at 11:58 AM, baptisteheyman wrote:
> > I've modified source/IoGLUTconst.h accordingly,
you can pull the 
> > patch
> > from me http://baptistehe
yman.dyndns.org/Io
> > I hope there are no other surprises, but yes feel
free to report
> other
> > compiler complaints 
> 
> Thanks Baptiste - I've pulled your changes to th main
repo.
> 
> Cheers,
> - Steve

I checked out last version from the darcs repository and now
the opengl
addon was built just fine. io still won't work, it aborts
with the same
segmentation fault message. Is there anything I can do to
help with
this? Meanwhile I will be using io_static that seems to
work.
Thank you very much.
Cheers,
Carlos


__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam
ˇgratis! 
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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

Hi Steve,

> Can you post the gdb backtrace?

here it is:

carlosmonad:/data1/install/Io-darcs/bin$ gdb io

(gdb) r
Starting program: /data1/install/Io-darcs/bin/io 
[Thread debugging using libthread_db enabled]
[New Thread 47848794429136 (LWP 5522)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47848794429136 (LWP 5522)]
Coro_StartWithArg (block=0xffffffffaa40fdb0) at
source/Coro.c:169
169     source/Coro.c: No such file or directory.
        in source/Coro.c

(gdb) backtrace
#0  Coro_StartWithArg (block=0xffffffffaa40fdb0) at
source/Coro.c:169
#1  0x00002b84aa4523d0 in swapcontext () from /lib/libc.so.6
#2  0x0000000000000000 in ?? ()

(gdb) 

Hope it helps.

Thank you.
Cheers,
Carlos


__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam
ˇgratis! 
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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

I would like to notice that both of my problems were already
reported as
issues 26 and 27 before:

26
[fixed] IoGLUTconst.h error:
initializer element is not constant
27
dynamic io seqfaults on AMD64

I've marked issue 26 as fixed. Don't know what is your
common practice,
perhaps it should be removed from the list.

Cheers,
Carlos


__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam
ˇgratis! 
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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

Hi all,

I want to help with this issue:

h
ttp://www.iolanguage.com/issues/view.cgi?number=34

The reasons are:

1) I find the collections library somewhat lagging behind
the language
simple and elegant design, IMHO they don't make justice to
Io.

2) I need to implement an homogeneous vector object (a la
numpy) and I
think it would fit nicely as a sequence in a collections
hierarchy.

3) I want to learn a bit about io internals.

That said, I would like to know:

a) Do you already have any design in mind?

b) What are the backwards compatibility constraints?

c) Regarding http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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

> * default implementations for a number of map-like
operations could be
> given for Collections, on top of a per-collection
implementation of
> foreach: map, reduce (fold), select... even O(n) size
and has
> operations. Of course these defaults will be overridden
by concrete
> collections in a sensible way.
> 
> * a simple Iterable interface, say next/hasNext, could
also be offered
> by Collections, just to be able to play the role of
other iterators that
> aren't collections.

I've been thinking a little more about these points. Last
year I did a
lot of python programming at work making heavy use of
iterators. That's
hardly a new concept, but what I found really interesting
was python
itertools module htt
p://docs.python.org/lib/module-itertools.html. It
provides a number of functions that one usually associate
with
"materialized" collections: take for example
ifilter, imap, izip, etc.
This way you not only don't need an initial collection to
start with,
but you don't even need to materialize intermediate results.
For
example, if I is an iterator over T, f a function T->T',
and p a
predicate T->bool, imap(f, ifilter(p, I)) would give you
a new iterator
I' over T' that will exclude elements for which p happens to
be false,
and transform the rest via f. Eventually you will want to
access the
elements yielded by I', so you will end up iterating over it
( for e in
I': ... ) or feeding a collection with it ( list(I') ). I
used to think
about this usage of iterators as somewhat of a delayed or
lazy
computation; you can even represent and manipulate infinite
streams this
way. So in this light, iterators turn out to have a number
of cool
features: they generalize collections, they avoid
materialization when
possible, they lazily delay operations over them. One thing
I don't find
that cool about the python implementation is the use of
standalone
functions instead of overriding common map, filter, etc
methods; but it
makes sense for python because map and filter are themselves
functions
and not members of any collection, so late binding is out of
question.

I think of an Iterable as an enumeration of objects given
one by one,
not necesarilly repeatable. On this basis a number of
operations can be
defined:

Iterable:
  foreach
  map
  select # aka filter
  reduce # aka fold
  # the following really make sense only if there exists an
underlying
  # notion of order:
  zip
  unzip
  slice
  count  # ( x1, x2, .... -> (0,x1), (1,x2), ....)
  ...

Thus Iterators would be one-time ephemeral Iterables:

Iterator < Iterable:
  next
  hasNext # or next could throw an exception instead

(Note that Iterable can be mostly implemented in terms of
abstract
next/hasNext. Working at the C level and carefully avoiding
unnecessary
lookups, I find this implementation a sensible compromise
between
simplicity and efficiency. Of course particular concrete
Iterators are
free to override some or all of these defaults)

While Collections could be seen as materialized, persistent
(in a loose
sense) Iterables:

Collection < Iterable:
  ...
  has
  size
  ...

It's expected that Collections offer Iterators that iterate
over their
elements, and that Collections can be constructed from
Iterators
enumerating their elements also. So Collections will also
include:

Collection < Iterable:
  ...
  iterator
  fromIterator
  ...

The Iterable interface provided by Collections can
essentially be seen
as a shortcut to the Iterable interface of their Iterators.
For example:

List.map f = List.fromIterator(List.iterator.map f)

(In general this implementation won't incur into
significative loss of
performance. I think in most cases a Collection could get
along with
just implementing next/hastNext/iterator/fromIterator
methods. But
again, relying in the defaults or not is up to each concrete
Collection.)

I also think that it's desirable that Iterable operations on
a
Collection give a Collection of the same type as result when
pertinent
(say map or select) instead of returning always Lists or
some other
fixed Iterable.

I will be working in a simple Io implementation of the above
as a proof
of concept. I would like to hear your commentaries and
suggestions.

Cheers,
Carlos

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam
ˇgratis! 
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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

Hi Jeremy,

> List's are implemented as Array's.

Yeah, I know that. But here I was referring to homogeneous
arrays, which
I need for a dsp, sound analysis/synthesys app, along the
same vein as
numpy arrays (see http://numpy.scipy.org/).
The point is to broadcast
operations on arrays elements to be able to implement
critical inner
loops in C. scheme has homogeneous vectors too
http://sr
fi.schemers.org/srfi-4/srfi-4.html, albeit not armed
with their
own number crunching methods like numpy ufuncs. I'm not
suggesting that
these should go into the standard library, but just giving
an example of
Sequence in which I'm particularly interested. In fact it's
pretty much
of an undertaking on its own that it deserves an addon.

> We use cursor objects for this. See the List/ListCursor
relationship.

I will take a look at cursors then.

> Specifically with regards to Ranges, I strongly suggest
that we stick 
> to someObject to(anotherObject) ... to create a range;
it just reads 

It's ok for me. range() was just an example of possible
sequence
constructor. I agree that someObject to(anotherObject) reads
better.

> better. Also "map()" isn't a good constructor
name unless we say 
> change all the SomeCollection map <-- naming to say:
SomeCollection 
> collect.

Mh, I see you point. Perhaps dict or table would be a better
name.

> Sets can be implemented ontop of Lists (and infact are;
c.f. List 
> appendIfAbsent, List union, List intersect, List
difference).

But element inclusion testing is the most characteristic
operation over
sets and it's implemented with O(1) on top of hash table or
with O(log
n) on top of tree, while in the best case it's also O(log n)
on top of
sorted list, but O(n) on vanilla list. Intersection, union
and
difference will be best implemented as merging operations in
case sets
are represented as sorted lists; otherwise union will
require an
additional O(n log n) sort at the end, while intersect and
difference
will require n O(log n) lookups. I'm not sure about what you
mean by
"implemented ontop of Lists". Could you be more
specific? Anyway
representing sets as hash tables is common place; of course
you lost the
ordering this way, but O(1) pays well.

Cheers,
Carlos


__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam
ˇgratis! 
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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

Hi Jeremy,

> List's are implemented as Array's.

Yeah, I know that. But here I was referring to homogeneous
arrays, which
I need for a dsp, sound analysis/synthesys app, along the
same vein as
numpy arrays (see http://numpy.scipy.org/).
The point is to broadcast
operations on arrays elements to be able to implement
critical inner
loops in C. scheme has homogeneous vectors too
http://sr
fi.schemers.org/srfi-4/srfi-4.html, albeit not armed
with their
own number crunching methods like numpy ufuncs. I'm not
suggesting that
these should go into the standard library, but just giving
an example of
Sequence in which I'm particularly interested. In fact it's
pretty much
of an undertaking on its own that it deserves an addon.

> We use cursor objects for this. See the List/ListCursor
relationship.

I will take a look at cursors then.

> Specifically with regards to Ranges, I strongly suggest
that we stick 
> to someObject to(anotherObject) ... to create a range;
it just reads 

It's ok for me. range() was just an example of possible
sequence
constructor. I agree that someObject to(anotherObject) reads
better.

> better. Also "map()" isn't a good constructor
name unless we say 
> change all the SomeCollection map <-- naming to say:
SomeCollection 
> collect.

Mh, I see you point. Perhaps dict or table would be a better
name.

> Sets can be implemented ontop of Lists (and infact are;
c.f. List 
> appendIfAbsent, List union, List intersect, List
difference).

But element inclusion testing is the most characteristic
operation over
sets and it's implemented with O(1) on top of hash table or
with O(log
n) on top of tree, while in the best case it's also O(log n)
on top of
sorted list, but O(n) on vanilla list. Intersection, union
and
difference will be best implemented as merging operations in
case sets
are represented as sorted lists; otherwise union will
require an
additional O(n log n) sort at the end, while intersect and
difference
will require n O(log n) lookups. I'm not sure about what you
mean by
"implemented ontop of Lists". Could you be more
specific? Anyway
representing sets as hash tables is common place; of course
you lost the
ordering this way, but O(1) pays well.

Cheers,
Carlos


__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam
ˇgratis! 
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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

> > We use cursor objects for this. See the
List/ListCursor relationship.
> 
> I will take a look at cursors then.

ListCursor
  collection 
  index 
  next 
  previous 
  setCollection 
  setIndex 
  type 
  value

Looks pretty much like a c++ stl random access iterator. It
could be
seen as a subclass of Iterator as was introduced in my
previous post I
guess. This way it would get the entire Iterable protocol
for free. I
like the name Cursor, I'm starting to think that it's more
appropriate
than Iterator, although not that widespread, at least
standing for
iterator. Nevertheless I will stick to it. BTW, how do you
check for the
end of the iteration? Does next throw an exception?

Another nice property of Iterable abstracting over
Collection and Cursor
this common map/select(/flatMap) protocol is the possibility
of
implementing sugar syntax for comprehensions on top of both
Collections
and Cursors. The Scala language is a good example of this,
see
http:
//scala.epfl.ch/intro/comprehensions.html. Python also
offers
generator comprehensions as well as list comprehensions. The
formers
return an iterator over the enumeration defined by the
comprehension,
while the latters materialize the enumeration into a list.
Generator
comprehensions are more general in the sense that you can
still build a
list, a set, a dictionary or any other collection from them
without
incurring significant additional costs (because you don't
construct an
ephemeral intermediate list just to immediately convert it
into another
kind of collection).

Cheers,
Carlos





__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam
ˇgratis! 
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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

> > We use cursor objects for this. See the
List/ListCursor relationship.
> 
> I will take a look at cursors then.

ListCursor
  collection 
  index 
  next 
  previous 
  setCollection 
  setIndex 
  type 
  value

Looks pretty much like a c++ stl random access iterator. It
could be
seen as a subclass of Iterator as was introduced in my
previous post I
guess. This way it would get the entire Iterable protocol
for free. I
like the name Cursor, I'm starting to think that it's more
appropriate
than Iterator, although not that widespread, at least
standing for
iterator. Nevertheless I will stick to it. BTW, how do you
check for the
end of the iteration? Does next throw an exception?

Another nice property of Iterable abstracting over
Collection and Cursor
this common map/select(/flatMap) protocol is the possibility
of
implementing sugar syntax for comprehensions on top of both
Collections
and Cursors. The Scala language is a good example of this,
see
http:
//scala.epfl.ch/intro/comprehensions.html. Python also
offers
generator comprehensions as well as list comprehensions. The
formers
return an iterator over the enumeration defined by the
comprehension,
while the latters materialize the enumeration into a list.
Generator
comprehensions are more general in the sense that you can
still build a
list, a set, a dictionary or any other collection from them
without
incurring significant additional costs (because you don't
construct an
ephemeral intermediate list just to immediately convert it
into another
kind of collection).

Cheers,
Carlos





__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam
ˇgratis! 
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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

> > * head and tail can be provided for Lists to
facilitate a recursive,
> > functional style, in case it were desired.
>
> Lists in Io are Arrays. LinkedLists would be a
different sort of 
> primitive.

Oh, I thought they were deques. Anyway I was thinking of
just adding
those methods, not moving to a car/cdr implementation that
faithfully
supports them.

> 
> > * default implementations for a number of map-like
operations could
> be
> > given for Collections, on top of a per-collection
implementation of
> > foreach: map, reduce (fold), select... even O(n)
size and has
> > operations. Of course these defaults will be
overridden by concrete
> > collections in a sensible way.
> 
> Those already exist, right?

Well I don't think they exist at that level in the
hierarchy, because to
start with there isn't even a Collection there. The point
was to provide
this outlined interface (that closely observes Io
nomenclature), and a
default implementation of most of its methods for free, to
every
Collection (and every Cursor/Iterator).

> > * variants for map-like operations that take
index,value and
> key,value
> > arguments would be provided at the Sequence and
Map level 
> > respectively.
> > Also at, putAt, indexOf, keyOf, etc messages make
sense at this
> level
> > too.
> 
> Those all exist already, don't they? Hint:

Of course I know they already exist. I haven't just come up
with exactly
the same names because of serendipity. As issue #34 states: 
"Move
strings into a String object and make Sequence hold
behaviour that can
be shared between Lists and Strings (and other sequential
types)" and as
I had proposed a more general Collection level above
Sequences, I was
trying to find a place for current Io's Lisp and Map
operations in that
tentative hierarchy.

Never mind. I won't go further with this, I've never
intended to change
Io apis in a way that would mess things up. In fact the
hierarchy
rearrangement I sketched was a pretty customary one. But you
are the cap
here, you know what is best for Io, and from the tone of
your answer
it's obvious that Collections and Iterables aren't. Message
received,
loud and clear.

Cheers,
Carlos

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam
ˇgratis! 
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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

> > * head and tail can be provided for Lists to
facilitate a recursive,
> > functional style, in case it were desired.
>
> Lists in Io are Arrays. LinkedLists would be a
different sort of 
> primitive.

Oh, I thought they were deques. Anyway I was thinking of
just adding
those methods, not moving to a car/cdr implementation that
faithfully
supports them.

> 
> > * default implementations for a number of map-like
operations could
> be
> > given for Collections, on top of a per-collection
implementation of
> > foreach: map, reduce (fold), select... even O(n)
size and has
> > operations. Of course these defaults will be
overridden by concrete
> > collections in a sensible way.
> 
> Those already exist, right?

Well I don't think they exist at that level in the
hierarchy, because to
start with there isn't even a Collection there. The point
was to provide
this outlined interface (that closely observes Io
nomenclature), and a
default implementation of most of its methods for free, to
every
Collection (and every Cursor/Iterator).

> > * variants for map-like operations that take
index,value and
> key,value
> > arguments would be provided at the Sequence and
Map level 
> > respectively.
> > Also at, putAt, indexOf, keyOf, etc messages make
sense at this
> level
> > too.
> 
> Those all exist already, don't they? Hint:

Of course I know they already exist. I haven't just come up
with exactly
the same names because of serendipity. As issue #34 states: 
"Move
strings into a String object and make Sequence hold
behaviour that can
be shared between Lists and Strings (and other sequential
types)" and as
I had proposed a more general Collection level above
Sequences, I was
trying to find a place for current Io's Lisp and Map
operations in that
tentative hierarchy.

Never mind. I won't go further with this, I've never
intended to change
Io apis in a way that would mess things up. In fact the
hierarchy
rearrangement I sketched was a pretty customary one. But you
are the cap
here, you know what is best for Io, and from the tone of
your answer
it's obvious that Collections and Iterables aren't. Message
received,
loud and clear.

Cheers,
Carlos

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam
ˇgratis! 
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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

> I don't understand - Did I say there was any problem
with the 
> hierarchy rearrangement you sketched?

No, because it felt like you kept suggesting "why don't
you just read
the docs before trolling?". And then I really caught
fire with that
sarcastic "Those all exist already, don't they? Hint:
Sequence slotNames
sort println". Perhaps I'm overreacting and I'd
apologize in that case.
But I think it's unfair to continuously remark that every
bit of
functionality I've mentioned Io already has, as if I was
criticizing its
lack of basic functionality like list indexing, which would
be nonsense.
On the contrary I was deliberately sticking to Io
nomenclature, so I
would have expected corrections more in the style of, say,
"Carlos: it's
atPut but *removeAt*, not atRemove, stick to our names
please" than
along the venue of "we already have atPut and removeAt,
just read the
docs". That said, I will continue working on the
homogeneous vector
library as an addon, and maybe on a generic data structures
& unicode
strings library on top of the c++ stl as a second one. Will
try to be
consistent with what is already done, but won't necessarily
keep
compatibility. I think things will go smoothly this way.

Cheers,
Carlos




__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam
ˇgratis! 
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar



 
Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

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

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

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

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