f-script-talk — Discussion about F-Script and related subjects

[F-Script-talk] Can I get access to the current block?

[Eric H. <eri...@gm...>]

Hi,

Block responds to return and return:.  Is it possible while in a block
to get access to the current block?

ie.

[ sys log:'hello'. <ref to current block> return.  sys log:'bye'. ] value.

So far I've only been able to figure it out if I bind the block to a variable.

b := [ sys log:'hello'. b return.  sys log:'bye'. ].
b value.


Is this functionality exposed to us?

Thanks,

Eric

[F-Script-talk] Sleep Scripting languge similar to FScript

[Giovanni G. <dai...@gm...>]

Hi,  I have found a java scripting language which is a mix of perl and
objective-c.
It is higly integrated with java:
 http://sleep.hick.org/

Give it a try ;)
-- 
Software Architect
http://www.objectsroot.com/
Software is nothing

Re: [F-Script-talk] NSThreads and F-Script

[Ken F. <ken...@gm...>]

On 9/9/06, Ken Ferry <ken...@gm...> wrote:
> On 9/8/06, Jeremy Sacket <js...@ga...> wrote:
> >
> > Is it possible
> > use (void)detachNewThreadSelector:(SEL)aSelector
> > toTarget:(id)aTarget withObject:(id)anArgument
> > inside a block and call another block that is defined.
> >
> > I.E something like...
> >
> > Thread:=[
> >  Do this in another tread.""
> >  pool := ((NSAutoreleasePool alloc) init).
> >  ......
> >  [pool release].
> >
> > ].
> >
> > NSThread detachNewThreadSelector:#thread toTarget:self
> > withObject:null.
>
>
>
> Not quite like that..

[snip]

Oops, didn't mean to send that!

I don't think you can do this without an objective-c helper today.
When a block receives the value message, F-Script's runtime retains
and autoreleases the block.  If you do

  NSThread NSThread detachNewThreadSelector:#value: toTarget:block
withObject:nil

there will be no pool in place to catch the autorelease message sent
to the block.

Anyway, the more interesting part is the thread safety of executing a block.

The release notes say that you cannot "share workspaces or block
environments between multiple threads".  From looking at the code, and
experimentally, it looks like it may be enough if a block uses only
local variables.  Philippe would have to say if that's guaranteed,
though.  I think Philippe is on vacation for a little while.

If that isn't enough: A block that you create with -[NSString asBlock]
has its own top-level workspace.  If you archive and unarchive a
block, that should also separate it from the current workspace.  A
high level way to do that would be to use distributed objects, for
which F-Script has some explicit support.  Again, I don't know what
Philippe would recommend.

Sorry for the partial information!

-Ken

Re: [F-Script-talk] NSThreads and F-Script

[Ken F. <ken...@gm...>]

On 9/8/06, Jeremy Sacket <js...@ga...> wrote:
>
> Is it possible
> use (void)detachNewThreadSelector:(SEL)aSelector
> toTarget:(id)aTarget withObject:(id)anArgument
> inside a block and call another block that is defined.
>
> I.E something like...
>
> Thread:=[
>  Do this in another tread.""
>  pool := ((NSAutoreleasePool alloc) init).
>  ......
>  [pool release].
>
> ].
>
> NSThread detachNewThreadSelector:#thread toTarget:self
> withObject:null.



Not quite like that..

First, pool := NSAutoreleasePool alloc init is similar to this Objective-C code:

    [aDictionary setObject:(NSAutoreleasePool alloc init) forKey:@"pool"]

When you bind the pool to the identifier p, the pool will receive a
retain message.  An autorelease pool will throw an exception if you
try to retain it.

You

here's what the release notes have to say:

"Note that you should not share workspaces or block environments
between multiple threads. If you need to execute multiple chunks of
F-Script code concurrently, you should use a different FSInterpreter
instance for each one."

If you detach a thread to a local block like that, you're sharing a
single workspace between multiple threads.  FScript isn't thread safe
in that way.

Also, pool := NSAutoreleasePool alloc init is similar to this Objective-C code:

    [aDictionary setObject:(NSAutoreleasePool alloc init) forKey:@"pool"]

When you bind the pool to the identifier p, the pool will receive a
retain message.  An autorelease pool will throw an exception if you
try to retain it.  You could work around this by using an NSValue
(wrappedPool := NSValue valueWithNonretainedObject:(NSAutoreleasePool
alloc init))

[F-Script-talk] NSThreads and F-Script

[Jeremy S. <js...@ga...>]

Is it possible use (void)detachNewThreadSelector:(SEL)aSelector  
toTarget:(id)aTarget withObject:(id)anArgument
inside a block and call another block that is defined.

I.E something like...

Thread:=[
	Do this in another tread.""
	pool := ((NSAutoreleasePool alloc) init).
	......
	[pool release].
].

NSThread detachNewThreadSelector:#thread toTarget:self withObject:null.

Re: [F-Script-talk] Multiple Blocks

[Jeremy S. <js...@ga...>]

Thanks Ken.  Works like a charm.

On Sep 8, 2006, at 2:04 AM, Ken Ferry wrote:

> On 9/7/06, Jeremy Sacket <js...@ga...> wrote:
>>
>> I am trying to implement extensions into my app.  I am wanting to  
>> define
>> blocks in one file and then run only blocks that I call.
>> Example:
>>
>> [
>>  name:=[ sys log:('Jeremy').]
>>  description:=[ :des| sys log:('des).]
>> ]
>>
>> Now I want to just execute the "name" block.
>
> Executing the big outer block will dump a definition for 'name' and
> 'description' in the enviroment that executes the block.  Executing
> the outer block will not execute the inner blocks.  So, you could do
> this:
>
> (typed in gmail, and skipping all the error handling for conciseness.
> Note that the example string above won't compile as a block.)
>
>> -(id)runProcedure
>> {
>>  // will set fscript to the above example.
>>  NSString *fscript = [procedure objectForKey:@"procedure"];
>
>   FSInterpreter *interpreter = [FSInterpreter interpreter];
>   System *sys = [interpreter objectForIdentifier:@"sys" found:NULL];
>   Block *outerBlock = [sys blockFromString:fscript]; // block is
> compiled in the environment of the interpreter
>   [outerBlock value]; //.. so the 'name' identifier is bound in the  
> interpreter
>   Block *nameBlock = [interpreter objectForIdentifier:@"name"  
> found:NULL];
>   [nameBlock value];
> }
>
> It might seem a little less indirect if the file contained statements
> without the big enclosing block.  Then you could use -[FSInterpreter
> execute:] to execute the string, and -[FSInterpreter
> objectForIdentifier:found:] to retrieve the blocks bound in the
> interpreter as a result.
>
> -Ken
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> F-Script-talk mailing list
> F-S...@li...
> https://lists.sourceforge.net/lists/listinfo/f-script-talk

Re: [F-Script-talk] Multiple Blocks

[Ken F. <ken...@gm...>]

On 9/7/06, Jeremy Sacket <js...@ga...> wrote:
>
> I am trying to implement extensions into my app.  I am wanting to define
> blocks in one file and then run only blocks that I call.
> Example:
>
> [
>  name:=[ sys log:('Jeremy').]
>  description:=[ :des| sys log:('des).]
> ]
>
> Now I want to just execute the "name" block.

Executing the big outer block will dump a definition for 'name' and
'description' in the enviroment that executes the block.  Executing
the outer block will not execute the inner blocks.  So, you could do
this:

(typed in gmail, and skipping all the error handling for conciseness.
Note that the example string above won't compile as a block.)

> -(id)runProcedure
> {
>  // will set fscript to the above example.
>  NSString *fscript = [procedure objectForKey:@"procedure"];

  FSInterpreter *interpreter = [FSInterpreter interpreter];
  System *sys = [interpreter objectForIdentifier:@"sys" found:NULL];
  Block *outerBlock = [sys blockFromString:fscript]; // block is
compiled in the environment of the interpreter
  [outerBlock value]; //.. so the 'name' identifier is bound in the interpreter
  Block *nameBlock = [interpreter objectForIdentifier:@"name" found:NULL];
  [nameBlock value];
}

It might seem a little less indirect if the file contained statements
without the big enclosing block.  Then you could use -[FSInterpreter
execute:] to execute the string, and -[FSInterpreter
objectForIdentifier:found:] to retrieve the blocks bound in the
interpreter as a result.

-Ken

[F-Script-talk] Multiple Blocks

[Jeremy S. <js...@ga...>]

I am trying to implement extensions into my app.  I am wanting to  
define blocks in one file and then run only blocks that I call.
Example:

[
	name:=[ sys log:('Jeremy').]
	description:=[ :des| sys log:('des).]
]

Now I want to just execute the "name" block.

-(id)runProcedure
{
	// will set fscript to the above example.
	NSString *fscript = [procedure objectForKey:@"procedure"];
	// Create a Block object from the string
	Block *myBlock = [fscript asBlock];
	
	// Can I do something like....
	// I know this is not a method on the Block class, but is there  
another way to get
	//subblocks from blocks?
	myBlock = [myBlock forName:@"name"];

	// Execute the block
	[myBlock value:@"name"];
	
}


Thanks,
Jeremy

[F-Script-talk] [IDEAS] Looking at Factor

[Giovanni G. <jj...@ob...>]

Hi,
surfing on the web I have found this new language:
http://factorcode.org/
It is a stack-based language with a very flexible parser.

It borrows idea from Self and it seems very promising to me.
And it has the concept of image, dynamic typing, inspector ...

As a plus, Factor can compile its code in x86 or PPC  in a snap and  
it promises good performance.

It will be not so difficult to create a (F)Smalltalk parser for  
generate an equivalent factor program.
I will explore this idea in the next weeks...
happy scripting ;)

-- 
    [   [  [ JJ ]  ]   ]  | First, they ignore you. Then they laugh
                          | at you. Then they fight you. Then you win
http://www.siforge.org   |          Mahatma Ghandi

Re: [F-Script-talk] Working out where FSInterpreter is

[Philippe M. <pm...@ac...>]

Le 1 sept. 06 =E0 19:11, Tim McDonald a =E9crit :

> Hi
>
> I'm playing around with f-script and it look super useful but I've
> run into a problem.
>
> I've inserted a nice flashy FSInterpreterView into my app using the
> IB paIette. However, i'd like to send some commands to the
> FSInterpreter associated with this view from my objective-c code
> (such as loading in certain objects). I know how to write the
> commands but I can't seem to work out how to find the FSInterpreter
> object I should send them to.

Hi,

You can get the interpreter associated with an interpreter view by =20
sending it the "interpreter" message. Example:

FSInterpreter *myInterpreter =3D [myInterpreterView interpreter];

Philippe

[F-Script-talk] Working out where FSInterpreter is

[Tim M. <t_m...@me...>]

Hi

I'm playing around with f-script and it look super useful but I've  
run into a problem.

I've inserted a nice flashy FSInterpreterView into my app using the  
IB paIette. However, i'd like to send some commands to the  
FSInterpreter associated with this view from my objective-c code  
(such as loading in certain objects). I know how to write the  
commands but I can't seem to work out how to find the FSInterpreter  
object I should send them to.

Any suggestions?

Cheers

Tim

Re: [F-Script-talk] Porting FScript to other O.S.: some questions

[Philippe M. <pm...@ac...>]

Le 25 ao=FBt 06 =E0 09:38, Giovanni Giorgi a =E9crit :

> FSCompiler.m is used to generate byte code?
> So FScript has also byte-code interpretation?!

FSCompiler does not generates byte-code per se, but a tree-based =20
structure that represent the parsed F-Script code. It's our =20
intermediate, optimized, code representation. We then feed the =20
interpreter with this structure.

> How can be difficult to make FScript multi-platform?
> For instance,  If we can have a stripped down version of FScript =20
> written in Java or C++, we can spread it also on Linux and Windows.
> It needn't to offer the same feature. Even the simple interpreter =20
> with a Plugin Architecture to extend it would be a strong starting =20
> point.
> What do you think?

I would be happy to see F-Script for Java or F-Script for .NET, for =20
example.

However, as other have said, you can't take F-Script as-is and =20
somewhat modify it to make it multi-platform, because one of its main =20=

point is to use a preexisting object model (this contributes to its =20
small footprint: it reuse a lot of the existing infrastructure). The =20
current implementation, for instance, does not have a layer of =20
abstraction that reduce adherence to the underlying object model. On =20
the contrary, it tries to integrate as deeply and closely as possible =20=

with it. So you would have to re-design and re-code it specifically =20
around another object model.

For scripting the Mac OS X object model, F-Script is the obvious =20
choice because Objective-C is itself based on Smalltalk in many ways. =20=

For Java, we would give-up some important synergies (for instance =20
Java methods are not keyword-based) but it still might be cool. Java =20
is relatively weak at supporting dynamic languages but this is going =20
to change with the introduction of the invokedynamic bytecode in the =20
next JVM and the potential introduction of hotswapping (the ability =20
to modify classes at run-time) in Java 7.
Anyway, to get back at your question, having a version of F-Script =20
for Java or any other object model would be a lot of work.

Currently the scripting languages for java that seem to be the most =20
promising are JavaScript (a complete implementation, bridged with =20
java and using the standard embedding API specified by the JSR 223 is =20=

going to be included in Java 6), Groovy, and BeanShell. I know that =20
people in charge of Java at SUN see JavaScript as having a big =20
potential to become a major general purpose scripting language for =20
the Java platform. On the other hand, Groovy has the huge advantage =20
to be based on the native Java object model, like F-Script is based =20
on the native Objective-C object model. But I would not be surprised =20
to see SUN aiming at somewhat creating a JavaScript implementation =20
based on the future Java object model (with hotswapping and al.). On =20
the Smalltalk-for-Java front, there are some interesting project like =20=

Bistro and SmalltalkJVM.

Best,

Philippe

[F-Script-talk] F-Script ideas

[Nathan S. <nat...@jp...>]

I've had a couple ideas with F-Script, and I was wondering if anyone  
else was interested in similar things:

- F-Script as a shell like bash, command line with syntax extensions  
for launching applications and dealing with files as you would use a  
shell

- A plotting library to be used with F-Script

-Nathan

Re: [F-Script-talk] Porting FScript ideas (!)

[Nathan S. <nat...@jp...>]

On Aug 29, 2006, at 11:15 PM, Giovanni Giorgi wrote:

>
> I have looked at objective-c on wikipedia, and some of its core idea
> hasn't yet been taken.

Apple has a very good short intro to Objective-C:

<http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/ 
ObjC.pdf#search=%22ObjC.pdf%22>

After that I'd recommend reading the F-Script source some...

If that gets you interested enough to buy a book, I highly recommend  
Aaron Hillegass' "Cocoa Programming for Mac OS X" and if you'd like  
to do graphics I'd recommend Garfinkel & Mahoney's "Cocoa Applications"

> The nasty pointers still are alive, and the lack of a garbage
> collection was major issues I suppose, to get broaden application.

GNUStep has garbage collection.  And Apple's version of Objective-C  
will get it soon according to some partial docs on Apple's websites.

-Nathan

Re: [F-Script-talk] Porting FScript ideas (!)

[Giovanni G. <jj...@ob...>]

On 30/ago/06, at 02:36, Marcel Weiher wrote:

> If you find Java too heavy, how would FScript built *on top of* Java
> help??

I am evaluating a set of option.
I used SmallTalk for my pleasure, but in the last 7 years my job was  
java-based.
Java is quite easy to learn and has a lot of support, it has pros and  
cons.

I don't like it but it is a killer-language if you must work in a  
team with different skills and tight schedule.
If you got something in Java, you can find more easily developers,  
support, friends and so on ;)
So I talked about Java as first option.


I have looked at objective-c on wikipedia, and some of its core idea  
hasn't yet been taken.
It is quite interesting language, my teacher at university didn't  
give it a chance.
The high dynamic idea with a old '80ths look for performance (=a  
strong C compiler inside) is interesting.
The nasty pointers still are alive, and the lack of a garbage  
collection was major issues I suppose, to get broaden application.

 >it's Smalltalk, not SmallTalk

Some other one corrected me saying the opposite :|
Isn't it the same?


-- 
Plus I remember being impressed with Ada because
you could write an infinite loop without a faked up condition.  The idea
being that in Ada the typical infinite loop would normally be  
terminated by
detonation. -Larry Wall                          [   [  [ JJ ]  ]   ]

Re: [F-Script-talk] Porting FScript ideas (!)

[Marcel W. <ma...@me...>]

On Aug 29, 2006, at 3:31 , Giovanni Giorgi wrote:

> In two words, I liked a  lot the *way* FScript uses Smalltak.

Hmm...it doesn't really *use* Smalltalk at all:  it *is* a Smalltalk  
that uses Objective-C, both as its implementation language and its  
object library.

>
> I have tried before to use scripting in Smalltalk with no much lucky.
> GNU Smalltalk and Squeak use a lot of resources, and Java is also  
> quite heavy.

If you find Java too heavy, how would FScript built *on top of* Java  
help??

> I think SmallTalk is an optimal glue, even better then AppleScript
> or perl.

Agreed.  In fact, Smalltalk (note:  it's Smalltalk, not SmallTalk) has  
always been about "connecting things", or as Alan Kay put it  
"ma" ("interstitialness").  I also think this can and needs to be  
taken further.

Cheers,

Marcel

Re: [F-Script-talk] F-Script-talk Digest, Vol 3, Issue 3

[Jan S. <Ja...@By...>]

> From: "Giovanni Giorgi" <dai...@gm...>
>
> Who can be interested in such a port in your own opinion?

Personally, I'm rather happy that it is so tightly integrated that it  
only works on MacOS X!

For one thing, that means it's efficient. If you start building f- 
script on top of Java, you're going to have a big, ugly, slow mess --  
sorta like Windows itself. :-)

:::: Discomfort, especially ethical discomfort, is a healthy  
alternative to ideological certainty. -- David Holmgren ::::
:::: Jan Steinman, http://www.EcoReality.org ::::

Re: [F-Script-talk] Porting FScript ideas (!)

[stephen w. <st...@ad...>]

On 29/08/2006, at 8:01 PM, Giovanni Giorgi wrote:
> GNU Smalltalk and Squeak use a lot of resources, and Java is also  
> quite heavy.

How about StepTalk?

--
   st...@ad...

[F-Script-talk] Porting FScript ideas (!)

[Giovanni G. <dai...@gm...>]

My concers is broader then stated before.
In two words, I liked a  lot the *way* FScript uses Smalltak.
The languages idea are important to me, the implementation is less important.
In FScript there are important implementation idea (for instance Cocoa
Integration), pulled up to the language level, so it is not easy
divide them.

I have tried before to use scripting in Smalltalk with no much lucky.
GNU Smalltalk and Squeak use a lot of resources, and Java is also quite heavy.
Scripting languages like Perl, Ruby and Python are showed different
ways of doing things.

I think SmallTalk is an optimal glue, even better then AppleScript
or perl.



On 8/29/06, stephen white <st...@ad...> wrote:
> On 29/08/2006, at 4:58 PM, Giovanni Giorgi wrote:
> > We can use reflection to get seamless integration (like BeansShell
> > does) at least at Java Level.
>
> It sounds like you're looking for a language, not F-Script in
> particular.
>
> F-Script is defined by Cocoa first and foremost, then the Array
> aspects, and finally as a Smalltalk dialect. So to truly port F-
> Script, you would need to port Cocoa as well.
>
> The cleanest way to achieve this is to improve the support for
> GNUstep on Windows (which isn't very good - aka, an opportunity for
> you to help!), then port to that environment with Objective C.
>
> Java's really not in the picture at all, unless you want to clone F-
> Script rather than port it.

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

Re: [F-Script-talk] Porting FScript to other O.S.: some questions

[stephen w. <st...@ad...>]

On 29/08/2006, at 4:58 PM, Giovanni Giorgi wrote:
> We can use reflection to get seamless integration (like BeansShell
> does) at least at Java Level.

It sounds like you're looking for a language, not F-Script in  
particular.

F-Script is defined by Cocoa first and foremost, then the Array  
aspects, and finally as a Smalltalk dialect. So to truly port F- 
Script, you would need to port Cocoa as well.

The cleanest way to achieve this is to improve the support for  
GNUstep on Windows (which isn't very good - aka, an opportunity for  
you to help!), then port to that environment with Objective C.

Java's really not in the picture at all, unless you want to clone F- 
Script rather than port it.

--
   st...@ad...

Re: [F-Script-talk] Porting FScript to other O.S.: some questions

[Giovanni G. <dai...@gm...>]

I think can be userful a re-implementation of FScript too.
There are plenty of language implemented in Java (jython, beanshell,
ecmascript, jruby, groovy and more recently some experiments of
Ingalls with Smalltalk).
Having a minimal implementation of FScript in Java would be a good
starting point.

We can use reflection to get seamless integration (like BeansShell
does) at least at Java Level.

A better starting point could be GNU Smalltalk o Squeak, but they
relay heavily on big startup images and this is not good for a
scripting language as I intend them.

Even Python is a good candidate in my humble opinion, because of its
huge support.

Ruby had a very small standard library and it is not suitable,
altrought it is very dinamically oriented and has unique feature.

I have seen the GNUStep site, but Windows support is lacking a lot,
and seems strong focused on Linux (even MacOSX support is
sub-optimal).

Who can be interested in such a port in your own opinion?
There are some users asking for a Fscript-like-version on Linux or Windooze?
Ciao ciao ;)


On 8/25/06, Todd Blanchard <tbl...@ma...> wrote:
>
> On Aug 25, 2006, at 12:38 AM, Giovanni Giorgi wrote:
> > How can be difficult to make FScript multi-platform?
>
> About as hard has making GNUStep multiplatform.
>
[...]
>
> FScript relies VERY heavily on the ObjectiveC runtime.  Without that,
> I don't think porting is a reasonable option.
>
[...]

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

Re: [F-Script-talk] Porting FScript to other O.S.: some questions

[Todd B. <tbl...@ma...>]

On Aug 25, 2006, at 12:38 AM, Giovanni Giorgi wrote:
> How can be difficult to make FScript multi-platform?

About as hard has making GNUStep multiplatform.

> For instance,  If we can have a stripped down version of FScript  
> written in Java or C++, we can spread it also on Linux and Windows.
> It needn't to offer the same feature. Even the simple interpreter  
> with a Plugin Architecture to extend it would be a strong starting  
> point.
> What do you think?

FScript relies VERY heavily on the ObjectiveC runtime.  Without that,  
I don't think porting is a reasonable option.

Re: [F-Script-talk] Dictionary and a shell command wanted :)

[Philippe M. <pm...@ac...>]

Le 25 ao=FBt 06 =E0 21:00, Giovanni Giorgi a =E9crit :

>
> On 24/ago/06, at 12:07, Philippe Mougin wrote:
>
>>
>>> NSObject subclass:'MyClass' instanceVariableNames:'a b c'
>>   MyClass
>>
>>> MyClass setFSBlock:[:self :_cmd| 'Method ' ++ _cmd ++ ' called on '
>>   ++ self printString] asInstanceMethod:#method1
>>
>>> myInstance :=3D MyClass alloc init
>>
>>> myInstance method1
>>   'Method method1 called on <MyClass: 0x4bb69c0>'
>>
>> Using the setFSBlock... methods you can also add methods to existing
>> Cocoa classes.
> Nice!
> How can  access to instance variable inside methods block?
> I tried with (self a)
> without so much success.
> Even valueForKey: didn't work :|

Here is an example using KVC to access instance variables:

  > MyClass setFSBlock:[:self| self setValue:33 forKey:'a'. self =20
valueForKey:'a'] asInstanceMethod:#method1

  > myInstance method1
  33

--Philippe

Re: [F-Script-talk] Porting FScript to other O.S.: some questions

[Nathan S. <nat...@jp...>]

On Aug 25, 2006, at 12:01 PM, Giovanni Giorgi wrote:

>
> On 25/ago/06, at 17:47, Nathan Strange wrote:
>
>>
>> On Aug 25, 2006, at 12:38 AM, Giovanni Giorgi wrote:
>>>
>>> How can be difficult to make FScript multi-platform?
>>> For instance,  If we can have a stripped down version of FScript
>>> written in Java or C++, we can spread it also on Linux and Windows.
>>> It needn't to offer the same feature. Even the simple interpreter
>>> with a Plugin Architecture to extend it would be a strong starting
>>> point.
>>> What do you think?
>>>
>>
>> Wouldn't GNUStep make more sense?
> GNUStep is a objective C port of NextStep?
> Mmmh I don't know it at all and I fear cannot be ported easily to
> Windows.
> Java  seems more easy to use as target language.

There is GNUStep for windows... don't know how complete it is though.

But F-script is written in Objective-C and it seems like a lot of  
work to re-write it in Java...  especially since Java may not support  
all of the Objective-C features used by F-script.

-Nathan

Re: [F-Script-talk] Porting FScript to other O.S.: some questions

[Giovanni G. <jj...@ob...>]

On 25/ago/06, at 17:47, Nathan Strange wrote:

>
> On Aug 25, 2006, at 12:38 AM, Giovanni Giorgi wrote:
>>
>> How can be difficult to make FScript multi-platform?
>> For instance,  If we can have a stripped down version of FScript
>> written in Java or C++, we can spread it also on Linux and Windows.
>> It needn't to offer the same feature. Even the simple interpreter
>> with a Plugin Architecture to extend it would be a strong starting
>> point.
>> What do you think?
>>
>
> Wouldn't GNUStep make more sense?
GNUStep is a objective C port of NextStep?
Mmmh I don't know it at all and I fear cannot be ported easily to  
Windows.
Java  seems more easy to use as target language.

-- 
    [   [  [ JJ ]  ]   ]  | http://www.squeak.org
                          |
http://www.siforge.org   |