If python goes Etoys, let's go scripting then - with the best IDE for creating and a clean license for running(!) scripts

On Aug 24, 2006, at 21:39 , Damien Pollet wrote:

> On 8/24/06, Marcel Weiher <[hidden email]> wrote:
>> Interesting discussion, as I have been wrestling with this very issue
>> in my Objective-Smalltalk / stsh work for some time now.
>
> can we play with stsh ? besides systrace shell google only found a
> mail from you :)

As it happens, I created an internal 'release' package the other day  
just before I stumbled on this thread.  The package can be found at:

        http://www.metaobject.com/downloads/Misc/stsh.tgz

This is not even a pre-release, binary only, only runs on Mac OS X  
(Tiger) and also comes with not documentation whatsoever, not even a  
Readme!  That said, I have been using it myself and it has proven  
quite useful.

Contents of the tar are a couple of frameworks that need to be put in  
a frameworks place ( /Library/Frameworks/ or ~/Library/Frameworks/ )  
and the stsh executable itself, which is probably best place in /usr/
local/bin/ .

As Smalltalkers, you will probably miss the Smalltalk class  
libraries:  they aren't there.  It's Objective-C and Cocoa underneath.

So it's NSArrays, NSStrings, and NSDictionaries, as well as those  
protocols:

 > 'Hello World' class.
NSCFString


Of course, that isn't all bad.  You have Foundation, AppKit, QTKit  
(QuickTime), WebKit, CoreImage and friends to play with.

Here is an example script, it uses QuickTime to concatenate a bunch of  
movies:

--------------- qtcat --------------------
#!/usr/local/bin/stsh

#---  load a framework we weren't linked against

qtkit := NSBundle bundleWithPath:'/System/Library/Frameworks/
QTKit.framework'.
qtkit load.

#---  command line parameters are passed in "args"

movieArgs := args.

#---  Objective-Smalltalk will convert a string to an Objective-C  
selector (SEL)

movieArgs := movieArgs sortedArrayUsingSelector:'numericCompare:'.

#---  Higher Order Messaging works...(what did you expect?!)

movies:=QTMovie collect movieWithFile:movieArgs each error:nil.
firstMovie := movies objectAtIndex:0.
restMovies := movies subarrayWithRange:(1 to:movies count-1).

#---   we will append the rest of the movies to the first movie,
#---   so we have to make that one editable.

firstMovie setAttribute:1 forKey:'QTMovieEditableAttribute'.

#----   Movie editing in QTKit is based on selections, so we
#----   have to do a 'select all' by getting the total range
#----   and then

ranges := restMovies collect movieAttributes collect  
objectForKey:'QTMovieActive
SegmentAttribute'.
0 to: restMovies count - 1 do: [ :i | (restMovies objectAtIndex:i)  
setSelection:
(ranges objectAtIndex:i) ].

#----   now do the append.

firstMovie do appendSelectionFromMovie:restMovies each.

#----  figure out a good name for the result

outName := (movieArgs objectAtIndex:0) stringByDeletingPathExtension.
outName := outName stringByAppendingString:'-full.mov'.
outputAttributes := NSMutableDictionary dictionary.

#----  flattening would be nicer, because then you don't have to keep  
the
#----  original files around, but sometimes doesn't work

#outputAttributes setObject:1 forKey:'QTMovieFlatten'.

#----  write the result

firstMovie writeToFile:outName withAttributes:outputAttributes.
#NSFileManager defaultManager do removeFileAtPath:movieArgs each  
handler:nil.

--------------- qtcat --------------------

Flames, comments, suggestions welcome.

And yes, there will be a real release, but I want to get the native  
code compilation a bit more complete than it is at the moment.

Marcel

On 8/25/06, Marcel Weiher <[hidden email]> wrote:
> As it happens, I created an internal 'release' package the other day
> just before I stumbled on this thread.  The package can be found at:

Yay!

> Flames, comments, suggestions welcome.

It has your homedir hardcoded somewhere (I first tried to run it from
the archive folder). Then after putting the frameworks under ~/Library
it made a bus error (on an intel mac). Are you planning to release the
sources ?

PS. not really related... what's the status of your Squeak /
Objective-C bridge ? there are a couple cocoa bridges out there, I'm
not sure which is the most advanced/maintained.

--
 Damien Pollet
 type less, do more

Very similar to FScript indeed.
You can obtain simial behavior using fscripter and FScript.
fscripter is an exacutable shell-command which sends the file to the FScript engine.







--
Software Architect
http://www.objectsroot.com/
Software is nothing

Bert Freudenberg <[hidden email]> writes:
> Reading this I'm not sure everybody is aware of how the chunk format
> works, because it actually is not declarative.

It's a philosophical question, actually.  It is declarative if you
want it to be.  FilePackage, for example, reads chunk format without
executing it.  It can do this because the actual uses of chunk format
are far less general than the general format Bert describes.  (Which,
by the way, is great to have written down, thanks!)

To put it another way, chunk format is executable, but that does not
mean you have to execute it.

This may seem like a nitpick, but I am jumping in because I keep
hearing people say that this or that is hard when using chunk format
because the files are not declarative.  They are declarative if you
want them to be, and there is a declarative-style reader already
implemented.


-Lex

Marcel Weiher <[hidden email]> writes:
> One idea that's been on my mind for a bit is that maybe for an OO
> scripting system, classes should be defined in separate script files?
> So the script file itself can define a sort of implicit class context,
> but this can vary.  Hmm..

That sounds good to me. Or maybe better, a script file could have an
*instance* of a particular (unnamed) class, unless you put a special
header at the top of the file to make it a re-instantiable class.
Defaults matter, and defining classes in script files is the less
common case.

Whether with classes or instances, "File scoped" variables could then
be instance variables.


I have often wished workspaces worked this way, by the way, but never
got around to implementing it....


-Lex

25 Aug 2006 15:10:43 +0200, Lex Spoon <[hidden email]>:
I really like this idea. I often asked myself why Ruby and Python
don't do that. This way they wouldn't need to implement puts and exit
in Object.

Philippe

On Aug 25, 2006, at 9:02 AM, Lex Spoon wrote:

True, but only up to a point.

(Most of) the chunk files in existence today can be parsed  
declaratively because they were generated automatically based on  
classes and methods in the image. The fileout code examines those  
objects and deterministically generates a program that will recreated  
them. Because we know how the fileout code works, we can infer the  
objects from the program without executing it.

However, the current discussion is about syntax for a scripting  
language. If chunk format was adopted, it would not be a  
philosophical question. Parsing would have to be specified to be  
either declarative or imperative. Humans writing chunk files with  
text editors would *not* produce files that could be parsed either way.

Colin

On Aug 25, 2006, at 13:14 , Damien Pollet wrote:

>> Flames, comments, suggestions welcome.
>
> It has your homedir hardcoded somewhere (I first tried to run it from
> the archive folder).

The install directory doesn't really matter in this case, but I will  
fix it to be relative...though it is very unlikely you will ever be  
able to run it without installing the frameworks in one of the fixed  
frameworks directories.

> Then after putting the frameworks under ~/Library
> it made a bus error (on an intel mac).

Odd.  I've tested it on both Intel and PPC Macs with various OSes.,  
but maybe there was something wrong with my tests.  Can you give me a  
few more details on the crash?

I've also just uploaded a new version of the package to the same  
location, but now with a 'version number' (0.1), a minute README and a  
couple more samples scripts.

> Are you planning to release the sources ?

Yes, at some point.  The MPWTalk framework is currently slighly less  
than 3KLOC.

>
> PS. not really related... what's the status of your Squeak /
> Objective-C bridge ? there are a couple cocoa bridges out there, I'm
> not sure which is the most advanced/maintained.

I think the one that Todd Blanchard worked on is the most recent and  
most comprehensive.  I certainly haven't worked on mine for ages and  
don't really plan on doing so.  While these sorts of bridges are sort  
of cool, I don't think they will ever give me the level of integration  
and "nativeness" that I would like to see.

Marcel

On 8/26/06, Marcel Weiher <[hidden email]> wrote:
> Odd.  I've tested it on both Intel and PPC Macs with various OSes.,
> but maybe there was something wrong with my tests.  Can you give me a
> few more details on the crash?

This time I removed the old binary and Frameworks, then installed the 0.1 ones.

dpollet@keima stsh-0.1 $ stsh scripts/fontnames.stsh
dyld: Library not loaded:
@executable_path/../Frameworks/MPWShellScriptKit.framework/Versions/A/MPWShellScriptKit
  Referenced from: /Users/dpollet/bin/stsh
  Reason: image not found
Trace/BPT trap

So I put back MPWShellScriptKit.framework from the old archive (it's
not in the 0.1) but then I get a bus error. Here's what gdb has to
say:

(gdb) run scripts/fontnames.stsh
Starting program: /usr/local/bin/stsh scripts/fontnames.stsh
Reading symbols for shared libraries
.....................................................................
done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000003
0x002972d8 in -[MPWFakedReturnMethodSignature initWithSignature:]
(self=0x40cd10, _cmd=0x2a6784, aSignature=0x40c950) at
/Volumes/User/marcel/programming/Kits/MPWFoundation/Collections.subproj/MPWFakedReturnMethodSignature.m:78
78      /Volumes/User/marcel/programming/Kits/MPWFoundation/Collections.subproj/MPWFakedReturnMethodSignature.m:
No such file or directory.
        in /Volumes/User/marcel/programming/Kits/MPWFoundation/Collections.subproj/MPWFakedReturnMethodSignature.m
(gdb) bt
#0  0x002972d8 in -[MPWFakedReturnMethodSignature initWithSignature:]
(self=0x40cd10, _cmd=0x2a6784, aSignature=0x40c950) at
/Volumes/User/marcel/programming/Kits/MPWFoundation/Collections.subproj/MPWFakedReturnMethodSignature.m:78
#1  0x9272f1b0 in -[NSObject(NSForwardInvocation) forward::] ()
#2  0x90a51ba1 in _objc_msgForward ()
#3  0x0008522e in -[MPWStsh initWithArgs:] (self=0xd9000,
_cmd=0x87a48, args=0x409290) at
/Volumes/User/marcel/programming/Kits/MPWShellScriptKit/MPWStsh.m:72
#4  0x00084d46 in +[MPWStsh runCommand:withArgs:] (self=0x893e0,
_cmd=0x87ab8, commandName=0x4083e0, args=0x409290) at
/Volumes/User/marcel/programming/Kits/MPWShellScriptKit/MPWStsh.m:26
#5  0x00084ed1 in +[MPWStsh runWithArgs:] (self=0x893e0, _cmd=0x87738,
args=0x407830) at
/Volumes/User/marcel/programming/Kits/MPWShellScriptKit/MPWStsh.m:37
#6  0x00002ef6 in main (argc=2, argv=0xbffff710) at
/Volumes/User/marcel/programming/Projects/stsh/stsh_main.m:14
(gdb)

> > PS. not really related... what's the status of your Squeak /
> > Objective-C bridge ? there are a couple cocoa bridges out there, I'm
> > not sure which is the most advanced/maintained.
>
> I think the one that Todd Blanchard worked on is the most recent and
> most comprehensive.

OK thanks :)


--
 Damien Pollet
 type less, do more

On Aug 26, 2006, at 23:23 , Damien Pollet wrote:

> On 8/26/06, Marcel Weiher <[hidden email]> wrote:
>> Odd.  I've tested it on both Intel and PPC Macs with various OSes.,
>> but maybe there was something wrong with my tests.  Can you give me a
>> few more details on the crash?
>
> This time I removed the old binary and Frameworks, then installed  
> the 0.1 ones.

OK, I tested on Intel 10.4 and lo and behold, it didn't work.  
Weird!   I've now recompiled and the 0.1.1 I just put up appears to  
work even on Intel 10.4 ... sigh.

Thanks for your help!

Marcel

On 8/27/06, Marcel Weiher <[hidden email]> wrote:
> Weird!   I've now recompiled and the 0.1.1 I just put up appears to
> work even on Intel 10.4 ... sigh.

It even works here :)

--
 Damien Pollet
 type less, do more

On Aug 27, 2006, at 10:33 PM, Damien Pollet wrote:

> On 8/27/06, Marcel Weiher <[hidden email]> wrote:
>> Weird!   I've now recompiled and the 0.1.1 I just put up appears to
>> work even on Intel 10.4 ... sigh.
>
> It even works here :)

Excellent!

Marcel