So...which is the status of Alien FFI ?
I remember Marco Schmidt did the first work of running FFI in windows...then
I think David was integrating such changes in VMMaker..
so, it is ready ? can be generate the plugin using VMMaker for winwows and
it just works?
Thanks for any update
Mariano
2010/5/31 Mariano Martinez Peck marianop...@gmail.com:
So...which is the status of Alien FFI ?
I remember Marco Schmidt did the first work of running FFI in windows...then
I think David was integrating such changes in VMMaker..
so, it is ready ? can be generate the plugin using VMMaker for
I'll note the most modern squeak VM's return wordSize, this might be
helpful somewhere.
wordSize
Answer the size (in bytes) of an object pointer.
Smalltalk wordSize
^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4]
On 2009-09-22, at 4:16 PM, Ken Treis
Hi Ken, sorry for the delayed reply. (i was away in summer school)
What i did , in my OpenGl binding that uses Alien is to reify the data
types.
For example, i created the class GLEnnum ( subclass of Alien).
You have to re-implement the method #dataSize, so you can just do
e :=
.
-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lawson English
Sent: Sunday, September 20, 2009 9:28 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Status of Alien FFI
Not meant
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko
Sent: Sunday, September 20, 2009 9:30 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Status of Alien FFI
To add some OT and concerns about Lua really cool stuff, see this video
http://vimeo.com
I hit a similar problem with ODBC on 64 bit systems. One caution though: we
can't completely lose control of the size when fixing this. One might need to
read something written by a 32 bit system on a 64 bit one. Just as with int
and DWORD, there needs to be a way to ask for the proper size
2009/9/19 Stefan Marr ph...@stefan-marr.de:
On 19 Sep 2009, at 08:46, Igor Stasenko wrote:
Lua is SLOW :)
But still - you can go and see the speed comparison of different
numerical algorythms implemented in different languages.
Squeak leaves Lua far behind..
That sounds like FUD.
But,
They probably moved while we got stuck.
This is all the story behind pharo: moving again.
Lua is SLOW :)
But still - you can go and see the speed comparison of different
numerical algorythms implemented in different languages.
Squeak leaves Lua far behind..
That sounds like FUD.
But, maybe
On 20.09.2009, at 13:49, Stéphane Ducasse wrote:
They probably moved while we got stuck.
It's like with money: there is an inflation of constant
progression. Everthing gets better slowly but constantly.
Over 10 years, this results in quite some progress.
Especially as you get the effect of
2009/9/20 Marcus Denker den...@acm.org:
On 20.09.2009, at 13:49, Stéphane Ducasse wrote:
They probably moved while we got stuck.
It's like with money: there is an inflation of constant
progression. Everthing gets better slowly but constantly.
Over 10 years, this results in quite some
...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko
Sent: Sunday, September 20, 2009 1:44 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Status of Alien FFI
2009/9/20 Marcus Denker den...@acm.org:
On 20.09.2009, at 13:49
@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Status of Alien FFI
2009/9/20 Marcus Denker den...@acm.org:
On 20.09.2009, at 13:49, Stéphane Ducasse wrote:
They probably moved while we got stuck.
It's like with money: there is an inflation of constant progression.
Everthing gets
Schwab,Wilhelm K wrote:
Sig,
If someone finds something truly better, more power to them. I predict Pharo
will be tough to beat though.
Bill
Not to rain on anyone's parade, but C# 4.0 is just around the corner and
MS is obviously grabbing features from everyone in existence...
@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Status of Alien FFI
Schwab,Wilhelm K wrote:
Sig,
If someone finds something truly better, more power to them. I predict Pharo
will be tough to beat though.
Bill
Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS
@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Status of Alien FFI
Schwab,Wilhelm K wrote:
Sig,
If someone finds something truly better, more power to them. I predict
Pharo will be tough to beat though.
Bill
Not to rain on anyone's parade, but C# 4.0 is just around the corner
: Sunday, September 20, 2009 7:13 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Status of Alien FFI
Schwab,Wilhelm K wrote:
Sig,
If someone finds something truly better, more power to them. I predict
Pharo will be tough to beat though.
Bill
Not to rain
in fact the meta level interface of the VM is missing.
And I would love to have what you describe.
When I was tired by smalltalk I was thikning to build one on top of lua.
Stef
On Sep 19, 2009, at 5:28 AM, Igor Stasenko wrote:
2009/9/18 Stéphane Ducasse stephane.duca...@inria.fr:
yes this is
2009/9/19 Stéphane Ducasse stephane.duca...@inria.fr:
in fact the meta level interface of the VM is missing.
And I would love to have what you describe.
When I was tired by smalltalk I was thikning to build one on top of lua.
Lua is SLOW :)
Once i recommended one game developer to use Lua for
probably but from a research vehicule perspective having a clean
system is a big win.
stef
On Sep 19, 2009, at 8:46 AM, Igor Stasenko wrote:
2009/9/19 Stéphane Ducasse stephane.duca...@inria.fr:
in fact the meta level interface of the VM is missing.
And I would love to have what you
On 19 Sep 2009, at 08:46, Igor Stasenko wrote:
Lua is SLOW :)
But still - you can go and see the speed comparison of different
numerical algorythms implemented in different languages.
Squeak leaves Lua far behind..
That sounds like FUD.
But, maybe I misunderstand you here.
However, Lua 5.x
Hi stefan
do you what they are really comparing?
because Smalltalk looks mysterious to me.
Stef
On Sep 19, 2009, at 10:41 AM, Stefan Marr wrote:
On 19 Sep 2009, at 08:46, Igor Stasenko wrote:
Lua is SLOW :)
But still - you can go and see the speed comparison of different
numerical
ok I saw smalltalk squeak
but then how do you interpret the graph?
On Sep 19, 2009, at 10:41 AM, Stefan Marr wrote:
On 19 Sep 2009, at 08:46, Igor Stasenko wrote:
Lua is SLOW :)
But still - you can go and see the speed comparison of different
numerical algorythms implemented in different
Well, the Language Shootout has some inherent problems.
But still, it gives a rough estimate over some interesting metrics,
especially execution time.
The main problem is to have efficient and well optimized
implementations of the benchmarks for each language.
And as far as I know, the Lua
On 19 Sep 2009, at 10:53, Stéphane Ducasse wrote:
ok I saw smalltalk squeak
but then how do you interpret the graph?
Well, the graphs are... creative...
At least not intuitive.
Change one of the languages to C, then you will get a feeling for what
they try to express.
If the first language,
Johan Brichau wrote:
On 16 Sep 2009, at 20:37, Ken Treis wrote:
* I'm creating a partial Alien library for GemStone so that I can
use the CairoGraphics package in both Pharo and GLASS. But on
x86-64, there there's a size difference between a pointer/long and
an integer. It'd be
yes this is one of my dream but
I'm not good enough to make it come true.
Stef
On Sep 18, 2009, at 6:40 PM, Lawson English wrote:
Johan Brichau wrote:
On 16 Sep 2009, at 20:37, Ken Treis wrote:
* I'm creating a partial Alien library for GemStone so that I can
use the CairoGraphics
2009/9/18 Stéphane Ducasse stephane.duca...@inria.fr:
yes this is one of my dream but
I'm not good enough to make it come true.
Lua is specifically designed from the very starting to live well as
embedded system, written in C. No wonder that its having very good C
interoperability.
And
On 16 Sep 2009, at 20:37, Ken Treis wrote:
* I'm creating a partial Alien library for GemStone so that I can
use the CairoGraphics package in both Pharo and GLASS. But on
x86-64, there there's a size difference between a pointer/long and
an integer. It'd be nice to have some more
Johan Brichau wrote:
On 16 Sep 2009, at 20:37, Ken Treis wrote:
* I'm creating a partial Alien library for GemStone so that I can
use the CairoGraphics package in both Pharo and GLASS. But on
x86-64, there there's a size difference between a pointer/long and
an integer. It'd be nice
It's fixed (except the AlienLoader -- read on).
The only problem was loading order.
I separated the extensions to the Parser (necessary to load the
primitive methods) into a separate package Alien-Prereqs.
If you load Alien-Prereqs before Alien-Core, it will work.
I'm now trying to adapt the
On Wed, Sep 16, 2009 at 10:06 AM, Johan Brichau
johan.bric...@uclouvain.bewrote:
It's fixed (except the AlienLoader -- read on).
The only problem was loading order.
I separated the extensions to the Parser (necessary to load the
primitive methods) into a separate package Alien-Prereqs.
If
On Wed, Sep 16, 2009 at 11:33 AM, Johan Brichau
johan.bric...@uclouvain.bewrote:
On 16 Sep 2009, at 10:33, Peter Hugosson-Miller wrote:
Is it possible to make 'Alien-Core' depend on 'Alien-Prereqs' (i.e.
a nested dependency)? If it were then the correct loading order
would be achieved
Probably that is the easiest solution.
Most of the time we did not rely on the dependencies because I'm not
sure that the
order can be specified.
I think that in the future we will use metacello to resolve this
ordering.
I'm just a bit lost in what is the preferred way of expressing
On Sep 16, 2009, at 1:06 AM, Johan Brichau wrote:
I separated the extensions to the Parser (necessary to load the
primitive methods) into a separate package Alien-Prereqs.
If you load Alien-Prereqs before Alien-Core, it will work.
Thanks Johan, that's good news here. I appreciate it.
Given
Hi ken
it is correct that alien touches the parser?
The declarations are not pragmas compliant.
Of course your suggestion makes sense.
When marcus is back in europe I will check the status of the
new handwritten parser because it would be good to use it.
Stef
On Sep 16, 2009, at 5:36 PM, Ken
On Sep 16, 2009, at 11:14 AM, Stéphane Ducasse wrote:
it is correct that alien touches the parser?
The declarations are not pragmas compliant.
Yes -- there's a hack in there that allows an error code variable to
be passed in the primitive pragma where otherwise the parser would
expect a
Ken Treis wrote:
* I'm creating a partial Alien library for GemStone so that I can use
the CairoGraphics package in both Pharo and GLASS. But on x86-64,
there there's a size difference between a pointer/long and an integer.
It'd be nice to have some more explicit APIs on Alien, so I could say
On Sep 16, 2009, at 11:54 AM, Stéphane Ducasse wrote:
what is the cairoPackage?
For pharo 1.1 I would like to see Rome cleaned and loadable/integrated
in pharo.
It's a port of Travis Griggs' package from VisualWorks -- a fairly
direct mapping of Cairo objects into Smalltalk. I posted it on
On Sep 16, 2009, at 12:02 PM, Douglas Brebner wrote:
One minor point is that whether integers and longs are different
depends
on the platforms data model. Under MS Win64, integers and long
integers
are both 32bit, while on most unixes integers are 32bit while long
ints
are 64bit.
On Wed, Sep 16, 2009 at 6:17 PM, Ken Treis k...@miriamtech.com wrote:
On Sep 16, 2009, at 12:02 PM, Douglas Brebner wrote:
One minor point is that whether integers and longs are different
depends
on the platforms data model. Under MS Win64, integers and long
integers
are both 32bit,
ok what is its license?
Stef
what is the cairoPackage?
For pharo 1.1 I would like to see Rome cleaned and loadable/
integrated
in pharo.
It's a port of Travis Griggs' package from VisualWorks -- a fairly
direct mapping of Cairo objects into Smalltalk. I posted it on
SqueakSource
Ken Treis wrote:
On Sep 16, 2009, at 12:02 PM, Douglas Brebner wrote:
One minor point is that whether integers and longs are different
depends
on the platforms data model. Under MS Win64, integers and long
integers
are both 32bit, while on most unixes integers are 32bit while long
The problem is that Pharo no longer considers the following primitive
call syntactically correct:
primitive: 'primCalloc' error: errorCode module: 'IA32ABI'
It does work if we omit the errorCode:
primitive: 'primCalloc' module: 'IA32ABI'
Was this change in the parser intended??
On 15 Sep
Yes because the intent was that the primitive would return a failure
error code versus prim failed, guess why?
On 9/15/09, Johan Brichau johan.bric...@uclouvain.be wrote:
The problem is that Pharo no longer considers the following primitive
call syntactically correct:
primitive: 'primCalloc'
My first reply was wrong. It seems that Alien's Parser extensions are
not loaded before the primitive methods, which is why it does not
accept them.
I'll try to fix this on the train to work.
On 16 Sep 2009, at 07:20, John McIntosh wrote:
Yes because the intent was that the primitive would
I'm unable to load Alien-Core into the latest Pharo (I'm on 10451),
mostly because the package overrides some methods in Scanner/Parser
and those overrides are out of sync with the current Pharo base. Is
anyone working on bringing these into sync? I would be glad to take a
stab at it but
Hi ken
fernando is the guy that fixed alien so he will probably reply to you
Stef
On Sep 14, 2009, at 11:36 PM, Ken Treis wrote:
I'm unable to load Alien-Core into the latest Pharo (I'm on 10451),
mostly because the package overrides some methods in Scanner/Parser
and those overrides are
48 matches
Mail list logo
