> Can you send me these missing files?

The problem with rsync seems to have ironed out, but I
get this error at the end.  The only part that seems
to have actual missing files is sqlite.

rsync error: some files could not be transferred (code
23) at
/home/lapo/packaging/tmp/rsync-2.6.0/main.c(1064)

These files are in
IoDesktop-2004-01-29/IoServer/SQLite/sqlite but do not
come across in rsync:

build.c
shell.c
sqlite_main.c
tclsqlite.c
tokenize.c
util.c
vdbe.c
vdbe.h
where.c

> What does uname return for you?

CYGWIN_NT-5.0

I don't have access to the msys machine, but I think
it just substitutes MSYS, to read MSYS_NT-5.0.  Older
versions would say MinGW_NT-5.0 instead, but Io
demands a pretty recent MSYS distribution anyway.

> I've had to many headaches with environment
> variables to condone
> requiring them.

Agreed, the interactions between the environment and
make are often ... interesting.  However, since uname
isn't going to return cygwin or msys in a
cross-compiling environment anyway, it makes sense to
not have the crosscompilation prefixes in the
Makefile.mingw.  If you're not averse to using GNUisms
in the makefile, you can replace CC=<whatever> with
CC?=<whatever> and it will only set it if it wasn't
already set before.  There's already gnuisms peppered
through the other makefiles, this one wouldn't hurt
(mingw is always going to use gmake anyway).

chuck

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

In response to a Python vs. Io thread I started at
comp.lang.python, someone found a segfault when
writing

2^1000

and concluded that the language was useless in its
current state. It looks like the error only affects
when 2 is put to some exponent that causes an
overflow. The following expression works:

4^500 //returns inf, not a segfault

So it seems to be specific to powers of 2.

Daniel Ehrenberg

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

On Sun, 1 Feb 2004, Daniel Ehrenberg wrote:
> In response to a Python vs. Io thread I started at
> comp.lang.python, someone found a segfault when
> writing
>
> 2^1000
[snip]

Intresting.  I'm diving into Io source for other reasons so I'll look into
it more.  The issue goes away when running the interpreter in GDB so it's
most likely something memory related.

Yours,

--
Kentaro A. Kurahone
SIGUSR1 Research and Development
"There's enough guilt in the world going around without grabbing for more."

On Sun, 1 Feb 2004, Austin K. Kurahone wrote:
> Intresting.  I'm diving into Io source for other reasons so I'll look into
> it more.  The issue goes away when running the interpreter in GDB so it's
> most likely something memory related.
It bugged me so I looked into this first.  It base/ByteArray.c
ByteArray_fromVargs_ the code is using sprintf to convert data.  The
problem is that the char buffer s line 838 in top of tree VM is statically
allocated to 100.  The reason why it exhibits itself with powers of 2 is
that there's a wide range of powers of 2 (~700 - 1020) that the math code
does not interpret as Inf and also has > 100 digits.  I'm fairly certain
that if you experiement with other base/exponent combinations the problem
will exhibit itself.

The quick fix: Change the size of s to 300.  This seems large enough.
The better fix: Change the size of s, and use snprintf.  If snprintf
returns a value greater than the fixed size, handle it as a NaN/Inf.

Yours,

--
Kentaro A. Kurahone
SIGUSR1 Research and Development
"There's enough guilt in the world going around without grabbing for more."

On Feb 1, 2004, at 9:12 PM, Austin K. Kurahone wrote:
> The quick fix: Change the size of s to 300.  This seems large enough.
> The better fix: Change the size of s, and use snprintf.  If snprintf
> returns a value greater than the fixed size, handle it as a NaN/Inf.

Thanks Austin (and thanks to Dan for reporting the bug). I've added a
fix. I couldn't find a BSD or similarly licensed version of snprintf(),
so I did the following. Does this look ok?:

void ByteArray_fromVargs_(ByteArray *self, const char *format, va_list
ap)
{
    char *s = malloc(1024);
    while (*format)
    {
      ...
        else if (*format == 'i' || *format == 'd')
        {
          int i = va_arg(ap, int);
          sprintf(s, "%i", i);
          ByteArray_appendCString_(self, s);
        }
        ...
      format++;
    }
    free(s);
}

-- Steve

On Feb 1, 2004, at 5:05 PM, Daniel Ehrenberg wrote:
> In response to a Python vs. Io thread I started at
> comp.lang.python...

Dan,

If you can get a feel from your discussion about what might make Io
more attractive to Python users, please let me know.

Cheers,
-- Steve

On Sun, 1 Feb 2004, Steve Dekorte wrote:
> Thanks Austin (and thanks to Dan for reporting the bug). I've added a
> fix. I couldn't find a BSD or similarly licensed version of snprintf(),
> so I did the following. Does this look ok?:
[snip]

Oops, forgot that snprintf was a BSDism.

Looks good, I take it that for the "f" case you're using the buffer on
the heap?  Io treats really large numbers as floats (or at least that
was the case that was trampling over the stack)...

--
Kentaro A. Kurahone
SIGUSR1 Research and Development
"There's enough guilt in the world going around without grabbing for more."

On Feb 1, 2004, at 9:58 PM, Austin K. Kurahone wrote:
> Oops, forgot that snprintf was a BSDism.

Oh good - I'll poke around the BSD source then. The only versions I saw
at first glance were GPLed.

> Looks good, I take it that for the "f" case you're using the buffer on
> the heap?

Yup.

-- Steve

All,

Attached is a patch that gets IoVM to compile and mostly work on IRIX 6.3

Changes implemented:
  * Added test for IRIX to Scheduler.c (Existing jmpbuf mangling is
    sufficient)
  * IRIX getcwd requires a non 0 size to be passed to getcwd[0].
  * Makefile hakery.
    * IRIX lacks ranlib.
    * The order in which libraries are listed during link matters more,
      reordered to make it work.

Caveats/Know issues:
  * Only tested with GCC 2.95.2 (I do not have access to MIPSpro)
  * ary.io performance test sigsegvs in malloc.
  * Number test fails more than usual (Floating point implementation
    gives incorrect results.)

I'm going to work on the sigsegv and the IoNumber issues.

Yours,

--
Kentaro A. Kurahone
SIGUSR1 Research and Development
"There's enough guilt in the world going around without grabbing for more."

[0]: I'm unsure of the implications of hardcoding the buffer to 1k, though
on most systems this should not make a difference.  Also note that the
existing code leaks the memory returned by getcwd.

Steve Dekorte writes:
  >
  > If you can get a feel from your discussion about what might make Io
  > more attractive to Python users, please let me know.

io has the better object system

Klaus Schilling

On Feb 2, 2004, at 1:37 AM, Austin K. Kurahone wrote:
  > Attached is a patch that gets IoVM to compile and mostly work on IRIX
6.3

Thanks! I'll add your changes.

> Also note that the existing code leaks the memory returned by getcwd.

I don't see this. The ByteArray and String calls are set to not copy,
so the String that is created should free the memory when collected.
Can you point out where you think the link is in more detail?

-- Steve

On Mon, 2 Feb 2004, Steve Dekorte wrote:
[snip]
> I don't see this. The ByteArray and String calls are set to not copy,
> so the String that is created should free the memory when collected.
> Can you point out where you think the link is in more detail?
Doh, missed that.  Sorry about that.

--
Kentaro A. Kurahone
SIGUSR1 Research and Development
"There's enough guilt in the world going around without grabbing for more."

Steve Dekorte wrote:
> Dan,
>
> If you can get a feel from your discussion about
> what might make Io
> more attractive to Python users, please let me know.
>
> Cheers,
> -- Steve

Here are some of the things that people didn't like
about Io:
*Not bug-free enough
*Not enough library bindings and documentation
*Too flexible
*If they wanted an "ultra-object oriented" programming
language, they'd use Smalltalk
*Difference between := and =

Some problems with Io implied by the Python philosophy
include:
*Not enough errors raised
*No easy list/map syntax discourages datastructures
*Have to close blocks
*Too object-oriented

Of all of these, the main thing IMHO that we could
realistically impliment without compromising Io's
design principles is the list/map syntax. It could be
handled by the preprocessor. Staying within the bounds
of Io's syntax, it could look somewhat like a
combination of Python's and Lua's syntaxes for similar
things. Lists would look like:
[1, 2, 3]
and be preprocessed into
List clone add(1, 2, 3)
and maps could look like
{x=5, y=2}
and be preprocessed into
Map clone atPut("x", 5) atPut("y", 2)

Alternatively, the "" slot could be extended to make
(1, 2) become a list and (x=5, y=2) to become a map,
but this has limitations (such as length 1 or 0 maps
or lists, or something like List clone add(x:=5),
which should work).

If you wanted to stay completely within the bounds of
Io's current syntax and not have limitations, I
already implimented something in Io that lets you
write stuff like in this format:
[(1, 2, 3)]
{(x=1, y=2, z=3)}
But this looks messy and creates too many slots in
Object (6, to make everything unambiguous and allow
for empty lists).

Daniel Ehrenberg

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

On Feb 2, 2004, at 1:19 PM, Daniel Ehrenberg wrote:
>   Lists would look like:
> [1, 2, 3]
> and be preprocessed into
> List clone add(1, 2, 3)
> and maps could look like
> {x=5, y=2}
> and be preprocessed into
> Map clone atPut("x", 5) atPut("y", 2)

There's a list() method on Object for lists:

list(1,2,3)

would it be acceptable to do the same for Map?

map(x=1, y=2)

Which could be implemented like:

Object map := method(
    m := Map clone
    m updateSlot := Map getSlot("atPut")
    thisMessage arguments foreach(arg, arg doInContext(m))
    m removeSlot("updateSlot")
    return m
)

-- Steve

On Feb 2, 2004, at 1:19 PM, Daniel Ehrenberg wrote:
> Here are some of the things that people didn't like
> about Io:
> *Not bug-free enough
> *Not enough library bindings and documentation

I agree. But we'll get there. :-)

> *Too flexible

This seems to be a common criticism of new languages. FORTRAN
programmers said this about C, and C++ and Java programmers have said
this about Python.

> *If they wanted an "ultra-object oriented" programming
> language, they'd use Smalltalk

Familiarity with prototypes might address this point.

-- Steve

Steve Dekorte wrote:
>
> On Feb 2, 2004, at 1:19 PM, Daniel Ehrenberg wrote:
> >   Lists would look like:
> > [1, 2, 3]
> > and be preprocessed into
> > List clone add(1, 2, 3)
> > and maps could look like
> > {x=5, y=2}
> > and be preprocessed into
> > Map clone atPut("x", 5) atPut("y", 2)
>
> There's a list() method on Object for lists:
>
> list(1,2,3)
>
> would it be acceptable to do the same for Map?
>
> map(x=1, y=2)
>
> Which could be implemented like:
>
> Object map := method(
>    m := Map clone
>    m updateSlot := Map getSlot("atPut")
>    thisMessage arguments foreach(arg, arg
> doInContext(m))
>    m removeSlot("updateSlot")
>    return m
> )
>
> -- Steve

I know. Actually, I actually made a version of that
myself. But it's still not as efficient as the builtin
syntax.

Daniel Ehrenberg

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

On Feb 2, 2004, at 5:38 PM, Daniel Ehrenberg wrote:
>> Object map := method(
>>    m := Map clone
>>    m updateSlot := Map getSlot("atPut")
>>    thisMessage arguments foreach(arg, arg
>> doInContext(m))
>>    m removeSlot("updateSlot")
>>    return m
>> )
>>
>> -- Steve
>
> I know. Actually, I actually made a version of that
> myself. But it's still not as efficient as the builtin
> syntax.

If we implemented the above in C (which is easy), it should be plenty
fast.

-- Steve

--- Steve Dekorte <steve@...> wrote:
>
> On Feb 2, 2004, at 5:38 PM, Daniel Ehrenberg wrote:
> >> Object map := method(
> >>    m := Map clone
> >>    m updateSlot := Map getSlot("atPut")
> >>    thisMessage arguments foreach(arg, arg
> >> doInContext(m))
> >>    m removeSlot("updateSlot")
> >>    return m
> >> )
> >>
> >> -- Steve
> >
> > I know. Actually, I actually made a version of
> that
> > myself. But it's still not as efficient as the
> builtin
> > syntax.
>
> If we implemented the above in C (which is easy), it
> should be plenty
> fast.
>
> -- Steve
>
>

I mean efficient to use, not fast. It's much more
verbose to write list(3) than [3].

Daniel Ehrenberg

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

-- En reponse de "Re: [Io] Python" de Daniel Ehrenberg, le 02-Feb-2004 :
> Steve Dekorte wrote:
>> Dan,
>>
>> If you can get a feel from your discussion about
>> what might make Io
>> more attractive to Python users, please let me know.
>>
>> Cheers,
>> -- Steve
>

I'd like to comment on a few of those I find interesting, since you
can pretty much summarize most the the rest as Io not being like python
(syntax-wise or design-wise).

> Here are some of the things that people didn't like
> about Io:
> *Not bug-free enough

This is not fair: of course bugs are discovered, but a fix is generally
released the same week. AFAIK there's never been a release where known bugs
haven't been fixed.

> *Not enough library bindings and documentation
> *If they wanted an "ultra-object oriented" programming
> language, they'd use Smalltalk

I grouped these two because I think they're both missing the same point: Io
is designed to be small, so it can be embedded easily. Neither Python are
smalltalk can be embedded, so let's move on to  something more interesting.

> *Too flexible

Ok, this one seems easy to dismiss, but I think it touches a sensible point
for an embeddable language. I find it quite hard to lock down Io so that
you can play within your sandbox without breaking the whole environment. I
know some people like the flexibility for experimenting (plus being able to
do '5 = "a"' scores high on coolness factor), but IMHO that's why Lua's so
successful.

For instance, take mod_io for apache where you can do something like:
<?io
   # script here
?>

That's nice, but if I'm an ISP providing mod_io as a service to customers,
I want to make sure that's safe for them to use.

Likewise, if I design a game where (power) users can script some aspects of
their characters, I don't want them to use some clever hack and cheat.

Again, I don't get the feeling Io allow to "jailroot" the interpreter
easily enough (so to speak)

Somebody proposed to "finalize" objects. I thought exceptions on := was
improving the situation (but I was wrong). I don't know how to solve that
right now.

> *No easy list/map syntax discourages datastructures

That's a good point, but honestly python gets it wrong too. Ruby's way is
nice: no tuple/list/map but a single List object. Methods can return
multiple values this way.

I had this idea for Io, but it seems like a big change in Io's syntax and
design ...  but that didn't stop me before, so here goes :-)

We could make it so what's passed to and from methods is one single List.

The list could have named elements to act like a map, or by default the
name would be the index. Example: l = (a, b, x=c, y=d, e) would allow you
to get l[1] -> a ; l[2] -> b ; l[3] -> c ; l[x] -> c ; etc.

You could define a method with default parameter values:
   z = method( a, b, x=888, y=999, e, # my code here )
and calling z(111,222,x=333,444) would set the local variables to:
   a = 111
   b = 222
   x = 333
   y = 999
   e = 444

Just like () is optional for methods when there is not parameter to pass,
(a) would be optional to set one single element, but could be mandatory to
set several:
   a = 123
   (b,c) = (234,456)
   (d,e) = myInit
of course, the following should do the right thing:
   (a,b) = (b,a)

This could allow an interesting polymophysm mechanism, where named
parameters would be included in the method name resolution:
   process = method(string=Nil, #code)
   process = method(int=Nil, #code)
and calling
   process(string="4")
I'm not sure how this could be implemented. And yes, you could do the same
with this ugly code:
   process = method(string=Nil, int=Nil,
               if (string!=Nil) # code
               else...
             )
but it's not pretty and doesn't play nice with inheritance.

There's a lot of question to be answered to get this complete, but I think
it's an interesting start.
If it's too traumatic for Io to handle, forget about it.

Eric

On Mon, 2 Feb 2004, Eric GAUDET wrote:
[snip]
> > *Not enough library bindings and documentation
> > *If they wanted an "ultra-object oriented" programming
> > language, they'd use Smalltalk
>
> I grouped these two because I think they're both missing the same point: Io
> is designed to be small, so it can be embedded easily. Neither Python are
> smalltalk can be embedded, so let's move on to  something more interesting.
Hmmm.  The documentation and library bindings will improve over time.  I'm
still not entirely happy with the current build system (though it is
improving).

> > *Too flexible
[snipity]
> That's nice, but if I'm an ISP providing mod_io as a service to customers,
> I want to make sure that's safe for them to use.
Hmmmm.  The way the mod_io internals are designed, it should be impossible
for one script snippet to interfere with another script snippet.  It was a
design concern to not allow the user to shoot others in their foot, just
themself.  That being said, if there's a bug in the VM that causes a
sigsegv, then it'll bring down the apache process.  (Though this is true
with any of the mod_$lang codes).  Apache runs as nobody so the impact of
a potential crash is somewhat mitigated.

> Likewise, if I design a game where (power) users can script some aspects of
> their characters, I don't want them to use some clever hack and cheat.
>
> Again, I don't get the feeling Io allow to "jailroot" the interpreter
> easily enough (so to speak)
That would be a implementation issue with the binding code between the VM
and the game.  IoVM library allows one to create multiple VM states,
effectively allowing for creation of sandboxes.

> Somebody proposed to "finalize" objects. I thought exceptions on := was
> improving the situation (but I was wrong). I don't know how to solve that
> right now.
That would be me.  It's relatively easy to implement, a quick hack to
get/set slot.  Personally I'd much rather have excessive massive overkill
amounts of flexibility than not.  I don't care for writing code with a
hand tied behind my back.

Yours,

--
Kentaro A. Kurahone
SIGUSR1 Research and Development
"There's enough guilt in the world going around without grabbing for more."

On Feb 2, 2004, at 9:24 PM, Eric GAUDET wrote:
>  I find it quite hard to lock down Io so that
> you can play within your sandbox without breaking the whole
> environment.

It used to me possible before mutable objects and the Locals object
were introduced. I think this is a really interesting and important
issue for languages if they are to be used as operating systems. It's a
tough problem though, and I don't have any solutions that I'm satisfied
with at this point.

> I know some people like the flexibility for experimenting (plus being
> able to
> do '5 = "a"' scores high on coolness factor), but IMHO that's why
> Lua's so
> successful.

AFAIKS, Lua, Python, Perl and Ruby are all at least as bad (and one
might say worse) in this respect because it they have directly
accessible globals and some don't support multiple states. Can you
describe how Lua is better in terms of sandboxing a bit more?

> Likewise, if I design a game where (power) users can script some
> aspects of
> their characters, I don't want them to use some clever hack and cheat.

How do you prevent this in Lua? Isn't the entire namespace is
accessible and therefore modifiable once you get a handle to the
globals, which can be done from anywhere?

> We could make it so what's passed to and from methods is one single
> List.

It basically is -  you can access them with "thisMessage arguments".

>  (b,c) = (234,456)

>  process = method(string=Nil, #code)

A special case check in updateSlot() could implement the first, and a
special case check in Block could implement the second. Would the added
complexity be worth it?

-- Steve

Given that Io's syntax seems to exist somewhere between LISP (just
parenthesized lists) and Algol (different syntaxes for different
semantic structures), would Io be considered a member of the LISP or
Algol family of languages?

-- Steve

> Can you describe how Lua is better in terms of sandboxing a bit more?

Lua doesn't have a real object model, and functions are not values, so you
cannot redefine basic behavior.

> > Likewise, if I design a game where (power) users can script some
> > aspects of
> > their characters, I don't want them to use some clever hack
> and cheat.
>
> How do you prevent this in Lua? Isn't the entire namespace is
> accessible and therefore modifiable once you get a handle to the
> globals, which can be done from anywhere?

When embedding Lua, you create an "interface" (C bindings and values you can
access) which is not modifiable from the Lua interpreter.
In Io, you would define an object with CFunction methods, but you can modify
it from the interpreter to make it completely different. Anything that can
be accessed can be modified by at least two or three mechanisms.

> > We could make it so what's passed to and from methods is one single
> > List.
>
> It basically is -  you can access them with "thisMessage arguments".

Perhaps it could be exposed to the user more.

> >  (b,c) = (234,456)
...
> >  process = method(string=Nil, #code)
>
> A special case check in updateSlot() could implement the first, and a
> special case check in Block could implement the second. Would
> the added complexity be worth it?

I don't know.

Eric

--- In iolanguage@yahoogroups.com, Steve Dekorte <steve@d...> wrote:
>
> Given that Io's syntax seems to exist somewhere between LISP (just
> parenthesized lists) and Algol (different syntaxes for different
> semantic structures), would Io be considered a member of the LISP
or
> Algol family of languages?

I'm no theory expert, but I'd say Algol, because something like "list
(1,2,3)" always has the semantic action of constructing a list, and
isn't just a list of symbols "list", 1, 2, and 3 that can be fed to
read then eval'd.  I mean, it's possible, but it takes more work.
For a sexp language, imagine XML, using a naive schema of (tagname
attributes contents): (document nil (foo ((attr1 val1) (attr2
value2)) (bar nil (#text () "hello world")))) .. enclose that form in
quote and it's data, pass it to a REPL and it's code (assuming you
attached semantic actions to each of the tags), put it in quasiquotes
and selectively eval for partial evaluation.  That's the essence of
LISP.

Arguably Common Lisp's proliferation of special forms makes it more
of an imperative language than it used to be, but you can get back
into that classic form if you want to.

I'm told that "slot based" languages are actually considered
somethign of a third category, which Self made famous.  Such
languages tend to use messages for everything (as Io does) and use
the policy of the current scope (static or dynamic or both) instead
of explicit selectors (Self did a bit of both).  If I can find the
paper on it, I'll post it.

Personally I love the heck out of Io's data model.  I enjoyed
programming in MOO (another prototype-based system), and Io frees me
from a lot of MOO's limitations.  All I need is orthogonal
persistence now and I'm in heaven. :)

chuck

> AFAIKS, Lua, Python, Perl and Ruby are all at least
> as bad (and one
> might say worse) in this respect because it they
> have directly
> accessible globals and some don't support multiple
> states. Can you
> describe how Lua is better in terms of sandboxing a
> bit more?

How are Io globals (I assume you mean things in the
Lobby) less accessable? All you have to do is prefix
the variable name with Lobby. I suppose this could be
overwritten, but you could always use Object proto as
a hack (and changing Object proto would probably be
too destructive).

> It basically is -  you can access them with
> "thisMessage arguments".

When you do that, it has to be evaluated because it is
still a message. While this helps for Io's extremely
flexible block syntax, it's usually an annoyance.
Sometimes it is hard to figure out which object should
evaluate them. I can't figure out how to evaluate it
in the scope that it is used instead of the scope that
method or block provides. If there were a convienence
function, say thisMessage evalArgs, to have the
arguments already be evaluated, it would help.

> A special case check in updateSlot() could implement
> the first, and a
> special case check in Block could implement the
> second. Would the added
> complexity be worth it?
>
> -- Steve

I don't really see the need for multiple assignment,
but for optional function arguments, it looks like it
would be very useful. Currently, to do an optional
function argument, you have to delve into messages,
something too complicated for the beginning
programmer. (even if Io shouldn't be used by beginning
programmers, it would still be more efficient to have
optional function arguments.) This looks like
something that should have a reference implementation
in Io; I'll work on that.

Daniel Ehrenberg

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

--- In iolanguage@yahoogroups.com, Daniel Ehrenberg
<littledanehren@y...> wrote:
> ...
> *Difference between := and =
>

I'm new to Io. I love the language, but I find this part quirky. Can
anyone give me a refresher on the origins of this?

For background, I'm an "everyday programmer" and I do mostly PHP for
my day job.

> ...
> *No easy list/map syntax discourages datastructures
>

I second this. It would be a nice addition. :)

> *Have to close blocks
>

I have nightmares about using tabs for scope, considering how many
different editors people are using around my office. Thank god for parens.

> > *Difference between := and =
> >
>
> I'm new to Io. I love the language, but I find this part quirky. Can
> anyone give me a refresher on the origins of this?
>

Basically, you cannot have a language that has both = doing creation and
updates, and also implicit scope (local or self).
We talked a lot about the benefits of either approach, and decided in favor
of := for creation, and = for update-only. Most languages require explicit
scope instead.

Eric

On Feb 3, 2004, at 10:46 AM, tlack_ wrote:
> --- In iolanguage@yahoogroups.com, Daniel Ehrenberg
> <littledanehren@y...> wrote:
>> *Difference between := and =
>
> I'm new to Io. I love the language, but I find this part quirky. Can
> anyone give me a refresher on the origins of this?

It allows us to avoid having to declare locals.

-- Steve

I was getting some errors "make"ing the latest IoServer release under
XP + Cygwin. The pcre library wouldn't link, and applying the
following diff seemed to work. Basically the script was attempting to
link the .la files together to form the object, but the .las were text
documents and not object files. No idea why this would happen.

Anyone else want to try it to see if I'm just crazy?

(I couldn't get SleepyCat DB to compile for the life of me, so I just
ended up omitting it from the binary. I can't wait for the
menu-oriented build.io script ;))

Here's the diff:

--- Makefile.orig 2004-02-01 18:36:24.733793600 -0500
+++ Makefile 2004-02-01 18:46:09.154148800 -0500
@@ -96,24 +96,24 @@
  OBJ = maketables.o get.o study.o pcre.o
  LOBJ = maketables.lo get.lo study.lo pcre.lo

-all:            libpcre.la libpcreposix.la pcretest pcregrep # winshared
+all:            libpcre.a libpcreposix.a pcretest pcregrep # winshared

-pcregrep: libpcre.la pcregrep.o # winshared
-  $(LINK) -o pcregrep pcregrep.o libpcre.la
+pcregrep: libpcre.a pcregrep.o # winshared
+  $(LINK) -o pcregrep pcregrep.o libpcre.a

-pcretest: libpcre.la libpcreposix.la pcretest.o # winshared
+pcretest: libpcre.a libpcreposix.a pcretest.o # winshared
 		 $(LINK) $(PURIFY) $(EFENCE) -o pcretest  pcretest.o \
-  libpcre.la libpcreposix.la
+  libpcre.a libpcreposix.a

-libpcre.la:     $(OBJ)
-  -rm -f libpcre.la
+libpcre.a:     $(OBJ)
+  -rm -f libpcre.a
 		 $(LINKLIB) -rpath $(LIBDIR) -version-info \
-  '$(PCRELIBVERSION)' -o libpcre.la $(LOBJ)
+  '$(PCRELIBVERSION)' -o libpcre.a $(LOBJ)

-libpcreposix.la: pcreposix.o
-  -rm -f libpcreposix.la
-  $(LINKLIB) -rpath $(LIBDIR) libpcre.la -version-info \
-  '$(PCREPOSIXLIBVERSION)' -o libpcreposix.la pcreposix.lo
+libpcreposix.a: pcreposix.o
+  -rm -f libpcreposix.a
+  $(LINKLIB) -rpath $(LIBDIR) libpcre.a -version-info \
+  '$(PCREPOSIXLIBVERSION)' -o libpcreposix.a pcreposix.lo

  pcre.o:  $(top_srcdir)/chartables.c $(top_srcdir)/pcre.c \
 		 $(top_srcdir)/internal.h $(top_srcdir)/printint.c \
@@ -148,7 +148,7 @@

  winshared : .libs/pcre.dll .libs/pcreposix.dll

-.libs/pcre.dll : libpcre.la
+.libs/pcre.dll : libpcre.a
 	 $(CC) $(CFLAGS) -shared -o $@ \
 	 -Wl,--whole-archive .libs/libpcre.a \
 	 -Wl,--out-implib,.libs/libpcre.dll.a \
@@ -157,15 +157,15 @@
 	 -Wl,--no-whole-archive
 	 sed -e "s#dlname=''#dlname='../bin/pcre.dll'#" \
 	 -e "s#library_names=''#library_names='libpcre.dll.a'#" \
- < .libs/libpcre.lai > .libs/libpcre.lai.tmp && \
- mv .libs/libpcre.lai.tmp .libs/libpcre.lai
+ < .libs/libpcre.ai > .libs/libpcre.ai.tmp && \
+ mv .libs/libpcre.ai.tmp .libs/libpcre.ai
 	 sed -e "s#dlname=''#dlname='../bin/pcre.dll'#" \
 	 -e "s#library_names=''#library_names='libpcre.dll.a'#" \
- < libpcre.la > libpcre.la.tmp && \
- mv libpcre.la.tmp libpcre.la
+ < libpcre.a > libpcre.a.tmp && \
+ mv libpcre.a.tmp libpcre.a


-.libs/pcreposix.dll: libpcreposix.la libpcre.la
+.libs/pcreposix.dll: libpcreposix.a libpcre.a
 	 $(CC) $(CFLAGS) -shared -o $@ \
 	 -Wl,--whole-archive .libs/libpcreposix.a \
 	 -Wl,--out-implib,.libs/pcreposix.dll.a \
@@ -174,12 +174,12 @@
 	 -Wl,--no-whole-archive .libs/libpcre.a
 	 sed -e "s#dlname=''#dlname='../bin/pcreposix.dll'#" \
 	 -e "s#library_names=''#library_names='libpcreposix.dll.a'#"\
- < .libs/libpcreposix.lai > .libs/libpcreposix.lai.tmp && \
- mv .libs/libpcreposix.lai.tmp .libs/libpcreposix.lai
+ < .libs/libpcreposix.ai > .libs/libpcreposix.ai.tmp && \
+ mv .libs/libpcreposix.ai.tmp .libs/libpcreposix.ai
 	 sed -e "s#dlname=''#dlname='../bin/pcreposix.dll'#" \
 	 -e "s#library_names=''#library_names='libpcreposix.dll.a'#"\
- < libpcreposix.la > libpcreposix.la.tmp && \
- mv libpcreposix.la.tmp libpcreposix.la
+ < libpcreposix.a > libpcreposix.a.tmp && \
+ mv libpcreposix.a.tmp libpcreposix.a


  wininstall : winshared
@@ -208,10 +208,10 @@

  install:        all # wininstall
 	        $(mkinstalldirs) $(DESTDIR)$(LIBDIR)
-        echo "$(LIBTOOL) --mode=install $(INSTALL) libpcre.la
$(DESTDIR)$(LIBDIR)/libpcre.la"
-        $(LIBTOOL) --mode=install $(INSTALL) libpcre.la
$(DESTDIR)$(LIBDIR)/libpcre.la
-        echo "$(LIBTOOL) --mode=install $(INSTALL) libpcreposix.la
$(DESTDIR)$(LIBDIR)/libpcreposix.la"
-        $(LIBTOOL) --mode=install $(INSTALL) libpcreposix.la
$(DESTDIR)$(LIBDIR)/libpcreposix.la
+        echo "$(LIBTOOL) --mode=install $(INSTALL) libpcre.a
$(DESTDIR)$(LIBDIR)/libpcre.a"
+        $(LIBTOOL) --mode=install $(INSTALL) libpcre.a
$(DESTDIR)$(LIBDIR)/libpcre.a
+        echo "$(LIBTOOL) --mode=install $(INSTALL) libpcreposix.a
$(DESTDIR)$(LIBDIR)/libpcreposix.a"
+        $(LIBTOOL) --mode=install $(INSTALL) libpcreposix.a
$(DESTDIR)$(LIBDIR)/libpcreposix.a
 	        $(LIBTOOL) --finish $(DESTDIR)$(LIBDIR)
 		 $(mkinstalldirs) $(DESTDIR)$(INCDIR)
 		 $(INSTALL_DATA) pcre.h $(DESTDIR)$(INCDIR)/pcre.h

--- In iolanguage@yahoogroups.com, "tlack_" <clackner@m...> wrote:
> I was getting some errors "make"ing the latest IoServer release
under
> XP + Cygwin. The pcre library wouldn't link, and applying the
> following diff seemed to work. Basically the script was attempting
to
> link the .la files together to form the object, but the .las were
text
> documents and not object files. No idea why this would happen.
>
> Anyone else want to try it to see if I'm just crazy?

Nope, you're not crazy, though it did drive me crazy to the point of
giving up on it.  It looks like PCRE itself has a wonky build
system.  I got it to build a static lib, but I had linker errors
later.  Might be that not all of the libs got built or something.
I'll give your patch a try and see how it goes.

> (I couldn't get SleepyCat DB to compile for the life of me, so I
just
> ended up omitting it from the binary.

Hm, on cygwin it should build more or less out of the box, but if you
have problems, you might want to build a more recent version and not
the version included with Io, then in IoDesktop/Sleepycat, grep
(recursively) for all the #includes containing "db/dist" and replace
it with #include <db.h>.  I have a fix at http://io.kicks-
ass.net/MingwStatus that has a tarball you can just unpack in
IoServer that should do that for you.

> I can't wait for the menu-oriented build.io script ;))

The way addons are structured, it does lend itself nicely to a menu
frontend to the build system.  I'm thinking of a web interface using
a tiny cgi server.  No point in reinventing the wheel writing my own
interface code after all.. But that's off somewhere in the future, I
want to get the makefiles sane first.

chuck