2010/5/31 Mariano Martinez Peck :
> 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
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
2
Please David :)
cleaning cleaning improvingletting people grow their understanding
and create new things
> The "pointer" terminology referring to words the object memory is
> needlessly
> confusing, I guess we should clean that up one of these days.
>
> Dave
>
>
>
On Tue, Sep 22, 2009 at 04:47:56PM -0700, John M McIntosh wrote:
>
> On 2009-09-22, at 4:16 PM, Ken Treis wrote:
>
> > Eliot, Johan, Fernando, et. al.:
> >
> > On Sep 16, 2009, at 3:09 PM, Eliot Miranda wrote:
> >
> >> Hi Ken,
> >>
> >> On Wed, Sep 16, 2009 at 12:17 PM, Ken Treis
> >> wrote:
>
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 w
Eliot, Johan, Fernando, et. al.:
On Sep 16, 2009, at 3:09 PM, Eliot Miranda wrote:
Hi Ken,
On Wed, Sep 16, 2009 at 12:17 PM, Ken Treis
wrote:
Perhaps there would need to be new primitives for the basic size of
each relevant C type? I'm anxious to hear what Eliot might have to
say about
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 f
ists.gforge.inria.fr
[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 thi
own thing.
-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
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 := GLEnum
Of Lawson
> English
> Sent: 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 pred
ember 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
@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#
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.
, September 20, 2009 2:32 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Status of Alien FFI
2009/9/20 Schwab,Wilhelm K :
> Sig,
>
> The term "bus factor" arose from legitimate concerns to be sure, but let's
> not start predicting Pharo's
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 :
>>
>> On 20.09.2009, at 13:49, Stéphane Ducasse wrote:
>>
>>> They proba
: pharo-project-boun...@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 :
>
> On 20.09.2009,
2009/9/20 Marcus Denker :
>
> 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.
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
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 F
2009/9/19 Stefan Marr :
>
> 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 m
Hi Stef,
The CairoGraphics package is MIT-licensed. I will update the
SqueakSource project page to reflect this.
Ken
On Sep 16, 2009, at 12:51 PM, Stéphane Ducasse wrote:
> ok what is its license?
>
> Stef
>
>> what is the cairoPackage?
>>> For pharo 1.1 I would like to see Rome cleaned and
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
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 com
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 d
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
>> numeri
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
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 :
>> in fact the meta level interface of the VM is missing.
>> And I would love to have what you describe.
>> When I was tir
2009/9/19 Stéphane Ducasse :
> 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 scripting..
and he wi
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 :
>> yes this is one of my dream but ...
2009/9/18 Stéphane Ducasse :
> 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 that's why, at the time i
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 Cair
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. I
Martin indeed it would be great to have a kind of standard
On Sep 18, 2009, at 12:57 AM, Martin McClure 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 package in both P
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
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 ex
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
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
> Squeak
On Wed, Sep 16, 2009 at 6:17 PM, 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 o
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 64b
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
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
I will let eliot comment on that because I'm alien newbie.
We cleaned it so that people can use it but
>
>> 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 prag
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 pragma where otherwise the parser would
expect a literal.
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 Tre
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 t
> 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 pac
On Wed, Sep 16, 2009 at 11:33 AM, Johan Brichau
wrote:
>
> 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
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.
I'm just a bit lost in what is the prefer
On Wed, Sep 16, 2009 at 10:06 AM, Johan Brichau
wrote:
> 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-Prere
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 A
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
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 wrote:
> The problem is that Pharo no longer considers the following primitive
> call syntactically correct:
>
>
> It does work if we omit the errorCode:
>
>
The problem is that Pharo no longer considers the following primitive
call syntactically correct:
It does work if we omit the errorCode:
Was this change in the parser intended??
On 15 Sep 2009, at 00:15, Stéphane Ducasse wrote:
> Hi ken
>
>
> fernando is the guy that fixed alien so he wil
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
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 I'
56 matches
Mail list logo
