On 2009-11-25, at 10:18 PM, bronxbomber92 wrote:

> Ahh. So this would be illegal?
>
> number := 1
> Foo = Object clone do (
>     bar := number
> )
>
> Btw, thanks for the quick reply!

That would work if number is in the Lobby (as Object inherits from Lobby) but
this wouldn't work:


test := method(
     number := 1
     Foo = Object clone do (
         bar := number
     )
)

test

Ahh. So this would be illegal?

number := 1
Foo = Object clone do (
      bar := number
)

Btw, thanks for the quick reply!

--- In iolanguage@yahoogroups.com, Steve Dekorte <steve@...> wrote:
>
>
> On 2009-11-25, at 9:12 PM, bronxbomber92 wrote:
>
> > I've seen the Object clone do ( ... ) syntax several times, but I don't see
any documentation on it.
> >
> > I can infer that code this:
> >
> > Foo := Object clone do (
> >    bar := 1
> >    baz := method(bar println)
> > )
> >
> > Is Functionally equivalent to this code?
> > Foo := Object clone
> > Foo bar := 1
> > Foo baz := method(bar println)
> >
> > Are there any other hidden semantics though?
>
> The difference is that the locals context of do() is the object it is being
called on - it doesn't have access to the locals in the scope that Object clone
do ( ... ) is called in.
>

On 2009-11-25, at 9:12 PM, bronxbomber92 wrote:

> I've seen the Object clone do ( ... ) syntax several times, but I don't see
any documentation on it.
>
> I can infer that code this:
>
> Foo := Object clone do (
>    bar := 1
>    baz := method(bar println)
> )
>
> Is Functionally equivalent to this code?
> Foo := Object clone
> Foo bar := 1
> Foo baz := method(bar println)
>
> Are there any other hidden semantics though?

The difference is that the locals context of do() is the object it is being
called on - it doesn't have access to the locals in the scope that Object clone
do ( ... ) is called in.

I've seen the Object clone do ( ... ) syntax several times, but I don't see any
documentation on it.

I can infer that code this:

Foo := Object clone do (
     bar := 1
     baz := method(bar println)
)

Is Functionally equivalent to this code?
Foo := Object clone
Foo bar := 1
Foo baz := method(bar println)

Are there any other hidden semantics though?

Thanks,
Jedd

(http://blip.tv/file/2229292/) 25:30 is interesting

Question:

"Usually when someone creates a new language they have something in
mind that they didn't find in another language.  Why did you write Ioke"

Answer:

"I wanted to see if the focus on performance in other languages was
one of the problems with them.  The goal is expressiveness. ... Ioke
is a language that I created only for me."

  From http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html

"The focus of programming language research for the last thirty years
has been to combine the expressive power of high level languages like
Smalltalk and the performance of low level language like C with little
attention paid to advancing expressive power itself. The result has
been a series of languages which are neither as fast as C or as
expressive as Smalltalk. Io's purpose is to refocus attention on
expressiveness by exploring higher level dynamic programming features
with greater levels of runtime flexibility and simplified programming
syntax and semantics."

Steve Dekorte wrote:
> On 2009-11-14, at 10:35 AM, Mike Austin wrote:
>  > I changed it to use block() and I do see different behavior -
>  > nothing happens
>  > at all now :)
>
> A block has to be called with the "call" method. I think what you want
> is:
>
> Test := Object clone do(
> init := method(
> self setIsActivatable(true)
> )
> activate := method(
> writeln(self == Lobby)
> ) setScope(thisContext)
> )
> test := Test clone
> test

Thanks Steve, it's working.  I'm playing around with state driven code, and it
seems like it can be done:

Buffer := Object clone do(
    full := clone

    init := method(
      self buffer := list()
      self setIsActivatable(true)

      self activate := method(
        if (buffer size > 2, self setProto(full))
        self
      ) setScope(thisContext)
    )

    put := method(value,
      writeln("Buffer put()")
      buffer append(1, 3, 3)
    )

    full put := method(value,
      writeln("Buffer full put()")
    )
)

buffer := Buffer clone
buffer put("abc")
buffer put("abc")

Mike

>

On 2009-11-14, at 10:35 AM, Mike Austin wrote:
> I changed it to use block() and I do see different behavior -
> nothing happens
> at all now :)

A block has to be called with the "call" method. I think what you want
is:

Test := Object clone do(
    init := method(
      self setIsActivatable(true)
    )
    activate := method(
      writeln(self == Lobby)
    ) setScope(thisContext)
)
test := Test clone
test

Jeremy Tregunna wrote:
>
>
> This is the way method dispatch works. your test message is found in the
> Lobby, and since the Lobby can get to Object's definition of
> isActivatable and Lobby doesn't have its own, it finds it on Object, but
> since it's a method, it's dynamically scoped so self points at the
> Lobby. Change activate to a block and you'll see different behaviour.

I changed it to use block() and I do see different behavior - nothing happens
at all now :)

Test := Object clone do(
    init := method(
      self setIsActivatable(true)
    )
    activate := block(
      writeln(self == Lobby)
      self
    )
)
test := Test clone
test

> On 2009-11-14, at 2:58 AM, Mike Austin wrote:
>
>  > I'm a little confused as to why self == Lobby in a new object's
> activate() slot:
>  >
>  > Test := Object clone do(
>  > init := method(
>  > self setIsActivatable(true)
>  > )
>  > activate := method(
>  > writeln(self == Lobby)
>  > )
>  > )
>  > test := Test clone
>  > test
>  >
>  > Any ideas? I'm using a recent git download, but it says Io 20090105 (??)
>  >
>  > Mike
>  >
>  >
>  >
>  > ------------------------------------
>  >
>  > Yahoo! Groups Links
>  >
>  >
>  >
>
> Regards,
>
> Jeremy Tregunna
> jeremy.tregunna@... <mailto:jeremy.tregunna%40me.com>
>
>

This is the way method dispatch works. your test message is found in the Lobby,
and since the Lobby can get to Object's definition of isActivatable and Lobby
doesn't have its own, it finds it on Object, but since it's a method, it's
dynamically scoped so self points at the Lobby. Change activate to a block and
you'll see different behaviour.

On 2009-11-14, at 2:58 AM, Mike Austin wrote:

> I'm a little confused as to why self == Lobby in a new object's activate()
slot:
>
> Test := Object clone do(
>   init := method(
>     self setIsActivatable(true)
>   )
>   activate := method(
>     writeln(self == Lobby)
>   )
> )
> test := Test clone
> test
>
> Any ideas?  I'm using a recent git download, but it says Io 20090105 (??)
>
> Mike
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Regards,

Jeremy Tregunna
jeremy.tregunna@...

I'm a little confused as to why self == Lobby in a new object's activate() slot:

Test := Object clone do(
    init := method(
      self setIsActivatable(true)
    )
    activate := method(
      writeln(self == Lobby)
    )
)
test := Test clone
test

Any ideas?  I'm using a recent git download, but it says Io 20090105 (??)

Mike

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	 iopackage johnsmith/foobar

and it would grab it from:

	 git://github.com/johnsmith/foobar

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

Thoughts?

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

http://iolanguage.com/

feedback welcome

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

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

Thanks
Justin

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

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

These need not be competing systems.

--
Samuel A. Falvo II

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

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

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

-- Danya.

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

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

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

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

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

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

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

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

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

Cheers
Justin

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

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

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

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

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

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

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

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

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

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

--
Samuel A. Falvo II

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

Here are some already existing projects:

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

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

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

What does everyone think?

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

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

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

> Regards
> Friedrich

Steve Dekorte <steve@...> writes:

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

Regards
Friedrich

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

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

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

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

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

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

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

Regards,

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

Sent from my iPhone

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

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