Steve, do you still have the code for this you were talking about?  I could
really use it now.  In fact all I need help with is implementing the part for
accepting arguments in the file-as-method.  I tried making files containing code
like:

// in file "myBlock.io"
block(a1, a2,
    mySlot := Object clone do( stuff )
)

or

// in file "myMethod.io"
method(a1, a2,
     mySlot := Object clone do( stuff )
)

and then running them like this:

// in a loader script
folderObject := Object clone
folderObject myBlock := doFile("myBlock.io")
folderObject myBlock call(a, b)

or

// in a loader script
folderObject := Object clone
folderObject myMethod := doFile("myMethod.io")
folderObject myMethod(a, b)

but my problem is I still want to be able to create slots in folderObject from
within the file script.  (By default it creates them in locals.)  In other words
what I really wanted is more like a "do()" but with arguments:

// in file "myMethod.io"
do(a1, a2,
     mySlot := ...
)

I'm not sure how to implement that.  Or is it better just use an explicit self:

// in file "myMethod.io"
method(a1, a2,
     self mySlot := ...
)

OK yeah that wasn't exactly what I thought I wanted, but I just tried it and
that might work instead.  It does successfully create a slot on the folderObject
when the method is executed.

I realized that won't be tedious to organize code this way after all, because
not every one-line method needs to be in a file by itself.  Instead, I'm
thinking of folders more as "module" objects, each file in the folder is a
method that, when called, defines a proto for a type in that module.  That proto
definition within the file can still itself contain many method definitions
within it.  You can gain some benefits from this way of organizing code, without
having to subdivide your codebase all the way down to individual methods.  You
just stop subdividing it at whatever granularity you're comfortable working
with.

--- In iolanguage@yahoogroups.com, Steve Dekorte <steve@...> wrote:
>
>
> On 2011-01-26 Wed, at 07:21 PM, dennisf486 wrote:
> > Steve, I'm not clear whether you mean Io objects should *act like* folders &
files, or if you meant to literally use file system folders to represent
objects.
>
> The latter.
>
> > If the latter I find this interesting because I've thought about this
myself.  My idea was that folders inside other folders would represent nested
objects.  I think if the structure of the files in the project and the structure
of the objects in the program, it is a big win.
>
> I was talking about it for proto definitions, but mapping the object graph to
the filesystem for persistence is also interesting to me.
>
> > I have already implemented a menu system for my game engine-with-Io
scripting, that uses Io files in a folder to create the game menus.  The names
of folders and files are used for menu commands, subfolders become sub-menus,
and when a menu item is selected it executes the Io code.
>
> Cool.
>
> > I had not considered makings individual methods go into files.  What are the
ramifications of that?  I can see where it might provide some interesting
possibilities, but could you be more specific about your reasoning for it?  I
could see it getting tedious to have every method in a separate file, if you had
many very small methods.  But I suppose someone could write an editor or IDE
that would manage them for you.
>
> I have some code for it that I need to release. One advantage is that it may
significantly reduce unnecessary version control conflicts as version control
systems understand the structure of the file system but not the structure of
code.
>
> Steve
>

In my game engine I now have over 64 Io scripts and probably 100 protos.  I
reference many 3rd-party libraries, and I want to know what scripts are
importing what types and organize the scripts so that as much as possible of the
rest of the game engine is still functional if a 3rd party library is removed. 
(For instance, a game server might retain the physics library but not load the
graphics library.)

It's taken me a long time to work out how I want to organize this, and
refactoring to support this new way of organizing is still in progress.  I
believe the way I've designed will solve a lot of my problems, but I'd be
interested in what others think.

My old way of organizing things was just lots of calls to "appendProto" to get
3rd-party dependencies' namespaces, and my startup script was just a long list
of "doRelativeFile".  I had to run the scripts in a certain order so that protos
one script needed to clone would existed when they were needed.  I also had
problems where two scripts developed mutual dependency on each other so that
either order of running them did not work.

I wanted to achieve three things with the new system:  run "doFile"
automatically by recursively finding all the ".io" files in all my script
directories, make scripts declare their dependencies and have them passed in
rather than the script reaching out to grab it on its own, and have the system
automatically wire up these dependencies.  The scheme I came up with should
achieve the first two goals, but does not address the third goal.  The
programmer still has to manually pass in the dependencies.

For this new style of organization, I tried to combine an idea floated on the
mailing list a while ago of folders-as-objects and files-as-methods, with the
concept from Gilad Bracha's Newspeak of not having a global namespace so that
scripts would be required to take their dependencies as arguments instead of
reaching out and getting them.

My new script loader creates a clone of a proto called "Module" for each
filesystem folder.  The module is named the same as the folder name.  Within
each module it creates slots named the same as the Io files in the folder, and
assigns to that slot the result of doFile on the script.  (And sub-folders
become sub-modules of the module, with the slot named the same as the folder
name.)

I've taken all my scripts and wrapped the entire code with a method block.  That
way instead of creating the proto directly, when doFile is run it just creates a
method which will be called later to create the proto.  Since Io is lazy and
dynamic, it doesn't try to resolve any names in the method body when the method
is declared, only when it is called.  So all the doFiles can run in any order
and create all the methods, without worrying about dependencies or mutual
dependencies at load time.

All of the dependencies the script has are method arguments to the outer method.
Therefore it has no dependencies on a global namespace; instead they are all
method arguments.

Inside the methods in my scripts files I've changed my proto declarations from
"name := proto clone" to "self name := proto clone".  Since "name" is the same
as the name of the file, which was used as the slot name, what happens is
running the method the first time *replaces* the slot which was a method that
creates the proto, with the proto itself.  So, in a configuration script you
must call the slot at least once and pass in the dependencies.  After that, the
slot in the module refers to the actual type created, instead of the method.

An example:

// in file "~/MyModule/Test.io"
method(Dependency, someValue,
self Test := Dependency clone do( x := someValue )
)

// in file "~/MyModule/Config.io"
method(Dependency,
Test(Dependency, 1234)
)

// in file "~/Startup.io"
MyModule := Module clone setDirectory("~/MyModule") doAllScripts
MyModule Config(SomeProto)

After the call to "doAllScripts" in startup, MyModule looks like this:
MyModule( Test := method(...) )

And after running "Config(SomeProto)", MyModule looks like this:
MyModule( Test := SomeProto( x := 1234 ) )

An important property of this system is sub-modules do NOT automatically get
access to the namespace of more-global modules.  I'm intentionally using a
capabilities-model to prevent that; submodules do not have any slot that
references their parent modules.  Instead, they must have things passed in from
higher up as method arguments in the Config script.  Config scripts at higher
levels pass needed dependencies down to Config scripts at lower levels.

I hit a snag in my script refactoring.  I'm trying to wrap all my proto
creations inside methods so that I can pass dependencies as arguments, but I
can't access the method arguments from inside a do block.

This works (because the appendProto is outside the do block):
// in file IdMap.io
method(namespace_std,
self IdMap := Object clone appendProto(namespace_std) do( /* other stuff */ ...
)
)

This does not work (but I wish it did):
// in file IdMap.io
method(namespace_std,
self IdMap := Object clone do(
appendProto(namespace_std)
/* other stuff */
)

The problem is that the method argument "namespace_std" is not in scope inside
the do-block.  In the case of one appendProto I can easily move the declaration
to the outside,
but this makes the declaration long when there are a lot of namespace-objects. 
And, I might want the argument for some other purpose than append proto.

I know that I could do something like:
self IdMap := Object clone
IdMap namespace_std := namespace std
IdMap do( ... )

But I'm trying to avoid the repetition of the word "IdMap".

I think one possible solution would be to make the method context a proto of the
object:
method(namespace_std,
self IdMap := Object clone appendProto(thisLocalContext) do(
appendProto(namespace_std)
)

Is this the best / only way?  One side effect of this trick is that all of the
method invocation's locals / arguments are now permanently uncollectible, even
if the args aren't all used, because thisLocalContext has a reference to them
and the object has a reference to thisLocalContext.  I suppose I could do
something weird like appendProto(thisLocalContext) at the top of the file and
removeProto(thisLocalContext) at the bottom of the file.  If I do this it would
make sense to make a method to do that automatically; I would call it
"doInLocalContext".

Why doesn't Io have a doInLocalContext method already?

On Thursday, 12 April, 2012 at 10:07 PM, dennisf486 wrote:

 

I hit a snag in my script refactoring. I'm trying to wrap all my proto creations inside methods so that I can pass dependencies as arguments, but I can't access the method arguments from inside a do block.

This works (because the appendProto is outside the do block):
// in file IdMap.io
method(namespace_std,
self IdMap := Object clone appendProto(namespace_std) do( /* other stuff */ ... )
)

This does not work (but I wish it did):
// in file IdMap.io
method(namespace_std,
self IdMap := Object clone do(
appendProto(namespace_std)
/* other stuff */
)

The problem is that the method argument "namespace_std" is not in scope inside the do-block. In the case of one appendProto I can easily move the declaration to the outside,
but this makes the declaration long when there are a lot of namespace-objects. And, I might want the argument for some other purpose than append proto.

I know that I could do something like:
self IdMap := Object clone
IdMap namespace_std := namespace std
IdMap do( ... )

But I'm trying to avoid the repetition of the word "IdMap".

I think one possible solution would be to make the method context a proto of the object:
method(namespace_std,
self IdMap := Object clone appendProto(thisLocalContext) do(
appendProto(namespace_std)
)

Is this the best / only way? One side effect of this trick is that all of the method invocation's locals / arguments are now permanently uncollectible, even if the args aren't all used, because thisLocalContext has a reference to them and the object has a reference to thisLocalContext. I suppose I could do something weird like appendProto(thisLocalContext) at the top of the file and removeProto(thisLocalContext) at the bottom of the file. If I do this it would make sense to make a method to do that automatically; I would call it "doInLocalContext".

Why doesn't Io have a doInLocalContext method already?

Haha OK I feel stupid, I just found "lexicalDo" in Io's C source code, it
appears it does exactly that.  Why doesn't lexicalDo show among the documented
Object methods in the Io Reference on the website?  And may I humbly suggest
adding lexicalDo to the Guide and/or the Tutorial?  I think this might be a pain
point for new users of Io; I'm not arguing that the default behavior of regular
"do" shouldn't be what it is, but I do think that it doesn't necessarily match a
new user's intuition, especially if they come from "strongly lexically scoped"
languages.  Presenting "do" and "lexicalDo" side-by-side would both avert that
potential confusion and be a primer for understanding scoping rules in Io in
general.

--- In iolanguage@yahoogroups.com, "dennisf486" <dennisf486@...> wrote:
>
> I hit a snag in my script refactoring.  I'm trying to wrap all my proto
creations inside methods so that I can pass dependencies as arguments, but I
can't access the method arguments from inside a do block.
>
> This works (because the appendProto is outside the do block):
> // in file IdMap.io
> method(namespace_std,
> self IdMap := Object clone appendProto(namespace_std) do( /* other stuff */
... )
> )
>
> This does not work (but I wish it did):
> // in file IdMap.io
> method(namespace_std,
> self IdMap := Object clone do(
> appendProto(namespace_std)
> /* other stuff */
> )
>
> The problem is that the method argument "namespace_std" is not in scope inside
the do-block.  In the case of one appendProto I can easily move the declaration
to the outside,
> but this makes the declaration long when there are a lot of namespace-objects.
And, I might want the argument for some other purpose than append proto.
>
> I know that I could do something like:
> self IdMap := Object clone
> IdMap namespace_std := namespace std
> IdMap do( ... )
>
> But I'm trying to avoid the repetition of the word "IdMap".
>
> I think one possible solution would be to make the method context a proto of
the object:
> method(namespace_std,
> self IdMap := Object clone appendProto(thisLocalContext) do(
> appendProto(namespace_std)
> )
>
> Is this the best / only way?  One side effect of this trick is that all of the
method invocation's locals / arguments are now permanently uncollectible, even
if the args aren't all used, because thisLocalContext has a reference to them
and the object has a reference to thisLocalContext.  I suppose I could do
something weird like appendProto(thisLocalContext) at the top of the file and
removeProto(thisLocalContext) at the bottom of the file.  If I do this it would
make sense to make a method to do that automatically; I would call it
"doInLocalContext".
>
> Why doesn't Io have a doInLocalContext method already?
>

On Thursday, 12 April, 2012 at 10:17 PM, dennisf486 wrote:

 

Haha OK I feel stupid, I just found "lexicalDo" in Io's C source code, it appears it does exactly that. Why doesn't lexicalDo show among the documented Object methods in the Io Reference on the website? And may I humbly suggest adding lexicalDo to the Guide and/or the Tutorial? I think this might be a pain point for new users of Io; I'm not arguing that the default behavior of regular "do" shouldn't be what it is, but I do think that it doesn't necessarily match a new user's intuition, especially if they come from "strongly lexically scoped" languages. Presenting "do" and "lexicalDo" side-by-side would both avert that potential confusion and be a primer for understanding scoping rules in Io in general.

--- In iolanguage@yahoogroups.com, "dennisf486" <dennisf486@...> wrote:
>
> I hit a snag in my script refactoring. I'm trying to wrap all my proto creations inside methods so that I can pass dependencies as arguments, but I can't access the method arguments from inside a do block.
>
> This works (because the appendProto is outside the do block):
> // in file IdMap.io
> method(namespace_std,
> self IdMap := Object clone appendProto(namespace_std) do( /* other stuff */ ... )
> )
>
> This does not work (but I wish it did):
> // in file IdMap.io
> method(namespace_std,
> self IdMap := Object clone do(
> appendProto(namespace_std)
> /* other stuff */
> )
>
> The problem is that the method argument "namespace_std" is not in scope inside the do-block. In the case of one appendProto I can easily move the declaration to the outside,
> but this makes the declaration long when there are a lot of namespace-objects. And, I might want the argument for some other purpose than append proto.
>
> I know that I could do something like:
> self IdMap := Object clone
> IdMap namespace_std := namespace std
> IdMap do( ... )
>
> But I'm trying to avoid the repetition of the word "IdMap".
>
> I think one possible solution would be to make the method context a proto of the object:
> method(namespace_std,
> self IdMap := Object clone appendProto(thisLocalContext) do(
> appendProto(namespace_std)
> )
>
> Is this the best / only way? One side effect of this trick is that all of the method invocation's locals / arguments are now permanently uncollectible, even if the args aren't all used, because thisLocalContext has a reference to them and the object has a reference to thisLocalContext. I suppose I could do something weird like appendProto(thisLocalContext) at the top of the file and removeProto(thisLocalContext) at the bottom of the file. If I do this it would make sense to make a method to do that automatically; I would call it "doInLocalContext".
>
> Why doesn't Io have a doInLocalContext method already?
>

If you want to make "do" be the same as "lexicalDo", you have my vote.

Otherwise, could we at least add an error path so that if an identifier is
unknown inside a "do" but is found in the lexical context, the error it gives to
the user explains the problem and suggests using lexicalDo?

--- In iolanguage@yahoogroups.com, Jeremy Tregunna <jeremy.tregunna@...> wrote:
>
> Given that this comes up every now and then (avg of once a year on this list
it seems), I think it's worth considering changing the behaviour of do(). It
only will have issues if people use = (not :=) inside do(). That's the only (as
I can see) case where it could introduce subtle bugs. As far as I know however,
no code does this (at least none of mine, and none of the standard lib code
does).
>
> Regards,
>
> Jeremy Tregunna
>
>
> On Thursday, 12 April, 2012 at 10:17 PM, dennisf486 wrote:
>
> >
> > Haha OK I feel stupid, I just found "lexicalDo" in Io's C source code, it
appears it does exactly that. Why doesn't lexicalDo show among the documented
Object methods in the Io Reference on the website? And may I humbly suggest
adding lexicalDo to the Guide and/or the Tutorial? I think this might be a pain
point for new users of Io; I'm not arguing that the default behavior of regular
"do" shouldn't be what it is, but I do think that it doesn't necessarily match a
new user's intuition, especially if they come from "strongly lexically scoped"
languages. Presenting "do" and "lexicalDo" side-by-side would both avert that
potential confusion and be a primer for understanding scoping rules in Io in
general.
> >
> > --- In iolanguage@yahoogroups.com (mailto:iolanguage%40yahoogroups.com),
"dennisf486" <dennisf486@> wrote:
> > >
> > > I hit a snag in my script refactoring. I'm trying to wrap all my proto
creations inside methods so that I can pass dependencies as arguments, but I
can't access the method arguments from inside a do block.
> > >
> > > This works (because the appendProto is outside the do block):
> > > // in file IdMap.io (http://IdMap.io)
> > > method(namespace_std,
> > > self IdMap := Object clone appendProto(namespace_std) do( /* other stuff
*/ ... )
> > > )
> > >
> > > This does not work (but I wish it did):
> > > // in file IdMap.io (http://IdMap.io)
> > > method(namespace_std,
> > > self IdMap := Object clone do(
> > > appendProto(namespace_std)
> > > /* other stuff */
> > > )
> > >
> > > The problem is that the method argument "namespace_std" is not in scope
inside the do-block. In the case of one appendProto I can easily move the
declaration to the outside,
> > > but this makes the declaration long when there are a lot of
namespace-objects. And, I might want the argument for some other purpose than
append proto.
> > >
> > > I know that I could do something like:
> > > self IdMap := Object clone
> > > IdMap namespace_std := namespace std
> > > IdMap do( ... )
> > >
> > > But I'm trying to avoid the repetition of the word "IdMap".
> > >
> > > I think one possible solution would be to make the method context a proto
of the object:
> > > method(namespace_std,
> > > self IdMap := Object clone appendProto(thisLocalContext) do(
> > > appendProto(namespace_std)
> > > )
> > >
> > > Is this the best / only way? One side effect of this trick is that all of
the method invocation's locals / arguments are now permanently uncollectible,
even if the args aren't all used, because thisLocalContext has a reference to
them and the object has a reference to thisLocalContext. I suppose I could do
something weird like appendProto(thisLocalContext) at the top of the file and
removeProto(thisLocalContext) at the bottom of the file. If I do this it would
make sense to make a method to do that automatically; I would call it
"doInLocalContext".
> > >
> > > Why doesn't Io have a doInLocalContext method already?
> > >
> >
> >
>

Those both sound like good ideas. I'd be happy to accept your github push
request for them :)

Steve

On 2012-04-12 Thu, at 09:17 PM, dennisf486 wrote:

> Haha OK I feel stupid, I just found "lexicalDo" in Io's C source code, it
appears it does exactly that.  Why doesn't lexicalDo show among the documented
Object methods in the Io Reference on the website?  And may I humbly suggest
adding lexicalDo to the Guide and/or the Tutorial?  I think this might be a pain
point for new users of Io; I'm not arguing that the default behavior of regular
"do" shouldn't be what it is, but I do think that it doesn't necessarily match a
new user's intuition, especially if they come from "strongly lexically scoped"
languages.  Presenting "do" and "lexicalDo" side-by-side would both avert that
potential confusion and be a primer for understanding scoping rules in Io in
general.

I am new to this language, and I love it.  I made first contact a couple of
months ago with the book 7 langs in 7 weeks.  But I have been really struggling
with trying to link to videos and manipulate them from within Io.  I want to
play sections off videos essentially.

I have put in a bit of time, and it seems that AVCodec is there and ffmpeg can
be used, but I'm lost.

I'm using Pardus Linux. Can anyone tell me how I setup my Io so I can use video,
and perhaps reference a program that shows video being used?

I really do love this language.

All Best,
Tom Kane

After reading Bruce A. Tate's 7 languages book, I wondered whether it
would be possible to configure IO to support the basic dependency syntax
of Unix make. I'm not concerned with full Makefiles, just the type of
output that you get from gcc with the -M (or -MM) options and similar
tools. At worst, this might be something like:

# comment
file.o: \
   file.h \
   file.cpp

IO already accepts \ for continuation lines and # for comments so I
thought I'd just need to define : as an assignment operator but this is
where I've hit a snag.

With “file: dep”, the colon appears to be treated as part of the
identifier. However, you can happily enter 1+1 so the same problem does
not apply to “+”.  This doesn't seem to match my understanding of IO's
grammar. Trying with :=, I get the following:

Io> value:="string"

   Exception: Slot value: not found. Must define slot using := operator before
updating.
   ---------
   message 'updateSlot' in 'Command Line' on line 1

Io> value := "string"
==> string

Is there any workaround for this?

I've used “call argAt(1) asString” to get the arguments in the
definition of the : operator. Is anyone aware of any parsing applied on
that argument that might prove troublesome?

Thanks

Oliver Kiddle

PS. Sorry if you receive this mail twice, I tried to send it shortly
after subscribing but it never arrived in the Yahoo group.

On Sunday, 15 April, 2012 at 4:08 PM, Oliver Kiddle wrote:

 

After reading Bruce A. Tate's 7 languages book, I wondered whether it
would be possible to configure IO to support the basic dependency syntax
of Unix make. I'm not concerned with full Makefiles, just the type of
output that you get from gcc with the -M (or -MM) options and similar
tools. At worst, this might be something like:

# comment
file.o: \
file.h \
file.cpp

IO already accepts \ for continuation lines and # for comments so I
thought I'd just need to define : as an assignment operator but this is
where I've hit a snag.

With “file: dep”, the colon appears to be treated as part of the
identifier. However, you can happily enter 1+1 so the same problem does
not apply to “+”. This doesn't seem to match my understanding of IO's
grammar. Trying with :=, I get the following:

Io> value:="string"

Exception: Slot value: not found. Must define slot using := operator before updating.
---------
message 'updateSlot' in 'Command Line' on line 1

Io> value := "string"
==> string

Is there any workaround for this?

I've used “call argAt(1) asString” to get the arguments in the
definition of the : operator. Is anyone aware of any parsing applied on
that argument that might prove troublesome?

Thanks

Oliver Kiddle

PS. Sorry if you receive this mail twice, I tried to send it shortly
after subscribing but it never arrived in the Yahoo group.

Jeremy Tregunna wrote:

> Your only real option is to force a whitespace between the identifier
> and the : to get around Io's use of it (solely for the purposes of the
> objc bridge I might add). Alternatively, you can write an actual parser
> and skip the DSL route.

I think that's a bit of a pity. I can really see why the DSL section is
included in the book because it is without doubt one of the things that
makes Io fascinating. It'd perhaps be intriguing to see what might be
possible if the definition of an identifier was configurable: something
like the GNU m4 changeword feature. Perhaps just within the scope of
parsing for a doString call.

It's interesting just trying to work out the rules for identifiers. In
the process I've realised that the "call argAt(1) asString" trick I had
tried for getting the list of files without requiring quoting would
fail for files starting with a number or containing a comma.

I've done a lot of experimenting with different make-like tools recently
and the Python/Ruby ones are really let down by needing excessive extra
syntax and other cruft. Io would be a lot better even without being able to
implement a subset of Unix make's syntax.

> On Sunday, 15 April, 2012 at 4:08 PM, Oliver Kiddle wrote:
> > PS. Sorry if you receive this mail twice, I tried to send it shortly
> > after subscribing but it never arrived in the Yahoo group.

I guess there must be a list moderator or something then for my message
to have taken three days.

Thanks for the answer.

Oliver

On Wednesday, 18 April, 2012 at 7:01 PM, Oliver Kiddle wrote:

 

Jeremy Tregunna wrote:

> Your only real option is to force a whitespace between the identifier
> and the : to get around Io's use of it (solely for the purposes of the
> objc bridge I might add). Alternatively, you can write an actual parser
> and skip the DSL route.

I think that's a bit of a pity. I can really see why the DSL section is
included in the book because it is without doubt one of the things that
makes Io fascinating. It'd perhaps be intriguing to see what might be
possible if the definition of an identifier was configurable: something
like the GNU m4 changeword feature. Perhaps just within the scope of
parsing for a doString call.

It's interesting just trying to work out the rules for identifiers. In
the process I've realised that the "call argAt(1) asString" trick I had
tried for getting the list of files without requiring quoting would
fail for files starting with a number or containing a comma.

I've done a lot of experimenting with different make-like tools recently
and the Python/Ruby ones are really let down by needing excessive extra
syntax and other cruft. Io would be a lot better even without being able to
implement a subset of Unix make's syntax.

> On Sunday, 15 April, 2012 at 4:08 PM, Oliver Kiddle wrote:
> > PS. Sorry if you receive this mail twice, I tried to send it shortly
> > after subscribing but it never arrived in the Yahoo group.

I guess there must be a list moderator or something then for my message
to have taken three days.

Thanks for the answer.

Oliver

Hi Tom,

I'm not on Linux so I can't help directly, but there is a Linux binary that
might have what you need on the io home page. Have you tried it?

Steve

On 2012-04-18 Wed, at 09:37 AM, tomkane63 wrote:

> I am new to this language, and I love it.  I made first contact a couple of
months ago with the book 7 langs in 7 weeks.  But I have been really struggling
with trying to link to videos and manipulate them from within Io.  I want to
play sections off videos essentially.
>
> I have put in a bit of time, and it seems that AVCodec is there and ffmpeg can
be used, but I'm lost.
>
> I'm using Pardus Linux. Can anyone tell me how I setup my Io so I can use
video, and perhaps reference a program that shows video being used?
>
> I really do love this language.

I have it set to moderate new user messages and then turn off moderation for
them if their first message is ok. Sorry that I'm not very diligent wrt new
messages.

On 2012-04-18 Wed, at 06:01 PM, Oliver Kiddle wrote:

>>
>> On Sunday, 15 April, 2012 at 4:08 PM, Oliver Kiddle wrote:
>>> PS. Sorry if you receive this mail twice, I tried to send it shortly
>>> after subscribing but it never arrived in the Yahoo group.
>
> I guess there must be a list moderator or something then for my message
> to have taken three days.

Glad to hear you found a solution - I didn't have any luck digging up that code.

On 2012-04-07 Sat, at 10:25 AM, dennisf486 wrote:

> OK yeah that wasn't exactly what I thought I wanted, but I just tried it and
that might work instead.  It does successfully create a slot on the folderObject
when the method is executed.
>
> I realized that won't be tedious to organize code this way after all, because
not every one-line method needs to be in a file by itself.  Instead, I'm
thinking of folders more as "module" objects, each file in the folder is a
method that, when called, defines a proto for a type in that module.  That proto
definition within the file can still itself contain many method definitions
within it.  You can gain some benefits from this way of organizing code, without
having to subdivide your codebase all the way down to individual methods.  You
just stop subdividing it at whatever granularity you're comfortable working
with.

Hi Steve,

Thanks for the response.  And I can see this might be outside your ken, and it's
purely an install problem, which is a bit murky in Linux.

I took down two downloadables from the website.  I actually have two machines -
an ubuntu and a Pardus.  Anyway, ubuntu 10.04.04  will take a debian build via
its package manager, and I installed the x86deb from the front page.  Strangely,
it doesn't have the AVCodec addon.  There are a lot of others though.

I also took down the linux x86rpm and that does have the AVCodec addon, but it
doesn't install via the ubuntu package manager, and when I installed via the
shell, it seemed to install ok in situ. But it didn't put the addons in the
right place.

What I'd like to do is either build my own addon for ubuntu to do ffmpeg
control, or maybe take the addon from the x86rpm and put that into my deb
install. My preference would be the second, because I want to get on and use
some video manipulation, but I'm happy to go the first route too.  Could you
give some advice?

All Best,
Tom


--- In iolanguage@yahoogroups.com, Steve Dekorte <steve@...> wrote:
>
>
> Hi Tom,
>
> I'm not on Linux so I can't help directly, but there is a Linux binary that
might have what you need on the io home page. Have you tried it?
>
> Steve
>
> On 2012-04-18 Wed, at 09:37 AM, tomkane63 wrote:
>
> > I am new to this language, and I love it.  I made first contact a couple of
months ago with the book 7 langs in 7 weeks.  But I have been really struggling
with trying to link to videos and manipulate them from within Io.  I want to
play sections off videos essentially.
> >
> > I have put in a bit of time, and it seems that AVCodec is there and ffmpeg
can be used, but I'm lost.
> >
> > I'm using Pardus Linux. Can anyone tell me how I setup my Io so I can use
video, and perhaps reference a program that shows video being used?
> >
> > I really do love this language.
>

Hello all,

Just posting to announce that I've updated the win32 binary package to fix a
directory structure issue I had in the previous release, leading to addons not
being found if Io was run from the wrong directory.  The binaries themselves
have not changed, just the directory structure.  If you're using the previous
release (20120302), here are instructions on how to fix your copy:

1) In the IoLanguage directory, please make two directories: "bin" and "lib"
2) In the bin directory, place the following files:
     - io.exe
     - io_static.exe
     - libbasekit.dll
     - libcoroutine.dll
     - libgarbagecollector.dll
     - libiovmall.dll
3) In the lib directory, place the rest of the files, along with the "io"
directory.  Also, copy the 4 .dlls from the bin directory into the lib
directory.
4) Update your PATH to point to IoLanguage\bin (optional)

If you'd rather just download the new copy which has this done for you, it's
available at the usual link on the IoLanguage.com homepage or the
iobin.suspended-chord.info homepage.

Thanks to those who sent in bug reports.
-->Jake

On 2012-04-30 Mon, at 04:52 AM, tomkane63 wrote:
> What I'd like to do is either build my own addon for ubuntu to do ffmpeg
control, or maybe take the addon from the x86rpm and put that into my deb
install. My preference would be the second, because I want to get on and use
some video manipulation, but I'm happy to go the first route too.  Could you
give some advice?

I'd recommend cloning the git repo and compiling it on linux. If you install the
dependencies, it should compile the video addons and install everything you
need.

Steve

So I've been using Io for a bit now, writing a package manager,
writing a few packages. I even wrote a syntax definition file for
Sublime Text 2.

One thing I've noticed since writing that defintion file is that it
doesn't seem like Io needs the "=" character in the assignment
operators.

Consider the following:

``` io
Version := Object clone do(
   major ::= 0
   minor ::= 0
   patch ::= 0

   asString := method( "#{major}.#{minor}.#{patch}"  )
)
```

Pretty simple object, right? Now imagine if you didn't need the `=` characters.

``` io
Version: Object clone do(
   major:: 0
   minor:: 0
   patch:: 0

   asString: method( "#{major}.#{minor}.#{patch}"  )
)
```

Smaller, slightly easier to read, and no confusion with the `==`,
`!=`, `+=`, `-=`, `>=`, `<=`, `~=`, `&=`, or `||=` operators that
usually crop up in programming languages.

Hi Kurtis,

An interesting idea. Self did something like this IIRC and I liked it, though it
fit in with their Smalltalk infix syntax better.
The motivation of using = was to graphically show the connection between =, :=
and ::=.
If we used : for := and :: for ::=, what would we use for =? Would it remain the
same?

Steve

On 2012-05-15 Tue, at 11:21 PM, Kurtis Rainbolt-Greene wrote:

> So I've been using Io for a bit now, writing a package manager,
> writing a few packages. I even wrote a syntax definition file for
> Sublime Text 2.
>
> One thing I've noticed since writing that defintion file is that it
> doesn't seem like Io needs the "=" character in the assignment
> operators.
>
> Consider the following:
>
> ``` io
> Version := Object clone do(
>  major ::= 0
>  minor ::= 0
>  patch ::= 0
>
>  asString := method( "#{major}.#{minor}.#{patch}"  )
> )
> ```
>
> Pretty simple object, right? Now imagine if you didn't need the `=`
characters.
>
> ``` io
> Version: Object clone do(
>  major:: 0
>  minor:: 0
>  patch:: 0
>
>  asString: method( "#{major}.#{minor}.#{patch}"  )
> )
> ```
>
> Smaller, slightly easier to read, and no confusion with the `==`,
> `!=`, `+=`, `-=`, `>=`, `<=`, `~=`, `&=`, or `||=` operators that
> usually crop up in programming languages.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Normally in Programming a numeric entity is called an Integer (when
it's not a Float, or similar complex number) and a series of
characters is called a String.

As a teacher of programming I often find myself explaining what String
and Integer are. They're not normally used words outside of
programming, math, or other complex scientific domains.

I've found, if a bit controversial, it much easier to call them by
their more used synonyms: Number & Text. People have a easier time
grasping onto that.

Thoughts?

On Wednesday, 16 May, 2012 at 3:07 PM, Kurtis Rainbolt-Greene wrote:

 

So while I like :: and : for setterSlot and setSlot symbols, ::: for setterSlot, :: setSlot, and : for updateSlot seems like overkill. Suggestions?

On Wed, May 16, 2012 at 3:23 AM, Jan-Paul Bultmann <janpaulbultmann@...> wrote:

 

It is there so that you can easily update Object members.

Take for example the following.

A := Object clone do(

x := 5

nonlocal := method(

x = 10

)

local := method(

x := 10

)

First case you assigned `A x` a new value.

Second case you created a local variable.

Cheers Jan

On May 16, 2012, at 8:21 AM, Kurtis Rainbolt-Greene wrote:

 

So I've been using Io for a bit now, writing a package manager,
writing a few packages. I even wrote a syntax definition file for
Sublime Text 2.

One thing I've noticed since writing that defintion file is that it
doesn't seem like Io needs the "=" character in the assignment
operators.

Consider the following:

``` io
Version := Object clone do(
major ::= 0
minor ::= 0
patch ::= 0

asString := method( "#{major}.#{minor}.#{patch}" )
)
```

Pretty simple object, right? Now imagine if you didn't need the `=` characters.

``` io
Version: Object clone do(
major:: 0
minor:: 0
patch:: 0

asString: method( "#{major}.#{minor}.#{patch}" )
)
```

Smaller, slightly easier to read, and no confusion with the `==`,
`!=`, `+=`, `-=`, `>=`, `<=`, `~=`, `&=`, or `||=` operators that
usually crop up in programming languages.

On Wednesday, 16 May, 2012 at 3:10 PM, Kurtis Rainbolt-Greene wrote:

 

Normally in Programming a numeric entity is called an Integer (when
it's not a Float, or similar complex number) and a series of
characters is called a String.

As a teacher of programming I often find myself explaining what String
and Integer are. They're not normally used words outside of
programming, math, or other complex scientific domains.

I've found, if a bit controversial, it much easier to call them by
their more used synonyms: Number & Text. People have a easier time
grasping onto that.

Thoughts?

I agree. "Text" might be a good change when we rewrite string to be UTF8 based.
Io already uses "Number", which is a C double.



On May 16, 2012, at 2:10 PM, Kurtis Rainbolt-Greene
<me@...> wrote:

> Normally in Programming a numeric entity is called an Integer (when
> it's not a Float, or similar complex number) and a series of
> characters is called a String.
>
> As a teacher of programming I often find myself explaining what String
> and Integer are. They're not normally used words outside of
> programming, math, or other complex scientific domains.
>
> I've found, if a bit controversial, it much easier to call them by
> their more used synonyms: Number & Text. People have a easier time
> grasping onto that.
>
> Thoughts?
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Radical, but I like our method of assignment in Acute (warning: may contain dragons).

Think of this psuedo-c code:

(&foo).set(1);

This above code would be seen as this: Get the address of some fictitious "foo" variable, and then set its value to 1. "foo" need not be in scope; if it's not, it would pick a location and return that. This works best in cases where you expose the underlying structure of your slot table in a meaningful way. You can make that intermediary an object, and return that from the 'address of' operator.

We're going to take a similar approach in Acute, though details aren't entirely fleshed out at the moment, so we're sticking with having only one form of assignment until that is known; setSlot.

The benefit of the above is also that assignment now takes only one argument. This was the last of the "Io Calculus" core primitives that we hadn't been able to factor out into a single argument method.