Trying to load ALienOpenGL into 4.1 alpha...

On 3/25/2010 9:04 AM, Igor Stasenko wrote:
No, because you're returning it and you can't share error code instances
(it's like saying that something that Point>>z:y: should just return the
same point for each call :-) It's fine to cache the call that way since
it's internal to the library but not for the return value.

> It is expected to see that marshalling/converting types takes most of the time,
> while rest should be same, because it straightforward: push arguments,
> make a call and return result.
> So, at some cases (not at all), one could prepare arguments and return
> value holder and then use it
> in calls, avoiding allocating&  converting them each time.

But what you call "preparing arguments and return value holder and then
use it" is marshalling. Moving it into the caller doesn't actually make
it faster. And how much time do you want to spend optimizing your use of
callout facilities vs. actually writing the app?

> For instance, when you passing a string (char*),
> one may use a CString object (a null-terminated String), and pass it
> into Alien without conversion,
> while FFI allocates a null-terminated strings on heap, copying String
> contents to that buffer and then using them as arguments to a
> function.

The FFI can do the same but it's mostly pointless. If you have a Squeak
string you can convert it to a C string (ExternalData) and pass it into
an FFI call.

> So its hard to say, which way is better.

There's no doubt in my mind. Absolutely nobody is going to spend time
optimizing their callout interface manually. They use the stuff that's
there. Go look at AlienOpenGL. Go look at Newspeak. That's your answer
right there. I have still to see a single example of a (non-contrived)
usage of Alien that's faster than the equivalent (non-contrived) FFI call.

Cheers,
   - Andreas

On 25 March 2010 18:35, Andreas Raab <[hidden email]> wrote: Well, it is up to the caller to decide, whether he wants to create a
new instance
for every return value, or use a single one.
For glGetError, this is fairly acceptable, because you can hide the
GLEnum instance inside the class
which implements glGetError.
Point taken.
Yes, you have to be a lot more clever to optimize such calls for your
use scenarios,
which, as you said, makes writing an application a lot more tedious process.
But it is the price we pay, when need something to be heavily optimized, isnt?

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 3/25/2010 9:48 AM, Igor Stasenko wrote:
True, but in that case, why not go straight to a plugin:

primitiveGlGetError
        <export: true>
        interpreterProxy pop: interpreterProxy methodArgumentCount+1.
        interpreterProxy pushInteger: self glGetError.

That's going to be faster than anything else.

Cheers,
   - Andreas

On 25 March 2010 18:54, Andreas Raab <[hidden email]> wrote:
Then i really wonder, why people find an Alien so attractive?

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 3/25/2010 10:30 AM, Igor Stasenko wrote:
> Then i really wonder, why people find an Alien so attractive?

There are two different reasons, one is philosophical, one is practical.
The practical issue is callbacks. When you need them you just need them :-)

The philosophical point is about how a system like Squeak should
integrate into the external environment. My opinion is that the VM
should provide a safe cross-platform abstraction layer. As a
consequence, I am in favor of plugins that provide abstractions, have a
well-defined interface, and are safe however you use them. The only real
sin I've ever committed in this regard was OpenGL because the interface
is so big and the handling of extensions tricky otherwise.

Gilad's opinion (and I hope I'm not misrepresenting him here since this
an extrapolation from discussions with Eliot) as far as I understand it
is that the VM should be basically invisible - just the execution
machinery and for the rest you go straight to the OS and do everything
there.

That's a perfectly valid position, and Alien makes that point quite
explicitly with moving even the marshalling into the image. I.e., what
Alien really provides is just an absolutely minimalistic thunk for
callout and callback; everything else is up to you. I can appreciate
that approach; it's just not my view on how a system like Squeak should
function.

I think what excites people who understand this is the philosophical
difference. Having access to everything at your fingertips is powerful,
no doubt about it.

Plus, most people have no clue what they're talking about when it comes
to plugins vs. FFI vs. Alien and just repeat what someone else said.
Sad, but true.

Cheers,
   - Andreas

On Thu, Mar 25, 2010 at 11:05 AM, Andreas Raab <[hidden email]> wrote:
And it's not only Gilad's opinion. The issue is not even _how_ to
integrate into the external environment, it's _whether_ to integrate
into it. You have to speak another language to integrate into another
culture. Systems relying on VM primitives with safe abstractions
choose to be tourists, and are bound to remain so.

As for performance, the penalty of high-level marshalling is only as
high as slowly high-level code runs.

Cheers,

--Vassili

On 25.03.2010, at 19:38, Vassili Bykov wrote:
Right - that's the way Squeak chose a long time ago. Run bit-identically everywhere, using the smallest possible interface to the host and do the rest on its own.

>> Plus, most people have no clue what they're talking about when it comes to
>> plugins vs. FFI vs. Alien and just repeat what someone else said. Sad, but
>> true.
>>
>> Cheers,
>>  - Andreas

Plus, Alien is newer, so must be better.

- Bert -

Andreas Raab wrote: How would a plugin work differently than the FFI's as far as safety goes?
EIther approach might make sense. The ability to do both gives
flexibility tot he platform, without detracting from any safety or
whatever issues... For a specific task, if you don't need XYZ,  don't
install it and and whatever its dependent on.


> I think what excites people who understand this is the philosophical
> difference. Having access to everything at your fingertips is
> powerful, no doubt about it.
>
> Plus, most people have no clue what they're talking about when it
> comes to plugins vs. FFI vs. Alien and just repeat what someone else
> said. Sad, but true.

I'm always trying to learn and I thank everyone for helping me. In this
context, though, while many projects, platforms, spheres of knowledge,
etc, suffer from lack of comprehension on the part of the masses, squeak
is probably more vulnerable to this issue than most because while it was
originally designed with beginners in mind, the primary users are
expert-level and beyond.

I have several main goals concerning squeak right now.

The first is to learn the system well enough to accomplish the rest.
The second is to explore various ways squeak and croquet/cobalt can
interop with the Second Life virtual world.
The third is to experiment with teaching using these technologies.

I'm a big fan of Salman Khan and the khan academy and a new convert to  
Norm Wildberger's lectures on youtube.

http://www.youtube.com/user/khanacademy
http://www.youtube.com/user/njwildberger


Squeak needs that level and sophistication of education applied to
*itself*.


Lawson

On 25.03.2010, at 21:59, Lawson English wrote:
>
> How would a plugin work differently than the FFI's as far as safety goes?

Instead of crashing, you get a nice friendly "primitive failed" error ;)

> EIther approach might make sense. The ability to do both gives flexibility tot he platform, without detracting from any safety or whatever issues... For a specific task, if you don't need XYZ,  don't install it and and whatever its dependent on.

That's exactly why we have FFI but use it as little as possible.

- Bert -

On 25.03.2010, at 21:59, Lawson English wrote:
>
> I'm a big fan of Salman Khan and the khan academy and a new convert to  Norm Wildberger's lectures on youtube.
>
> http://www.youtube.com/user/khanacademy
> http://www.youtube.com/user/njwildberger

I didn't know Khan Academy, thanks!

I bought Wildberger's book a while ago. But seeing his lectures now gives a very nice perspective. Who'd have thunk trigonometry could be friendly? ;)

> Squeak needs that level and sophistication of education applied to *itself*.
>
> Lawson

Hear, hear!

- Bert -

Bert Freudenberg wrote:
1200+ lectures on youtube and counting. Quit his day job to work ont eh
project and is getting awards and grants all over (not to mention loads
of publicity).

> I bought Wildberger's book a while ago. But seeing his lectures now gives a very nice perspective. Who'd have thunk trigonometry could be friendly? ;)
>
>  


I'm watching his linear algebra series. Illuminates some very obscure
corners, for me. High school-oriented math FTW!

>> Squeak needs that level and sophistication of education applied to *itself*.
>>
>>    
Have you ever watched a ZBrush tutorial in ZBrush itself? I think a
great use-case for squeak would be to create ZBrush level tutorials with
2D and 3D graphics (including replayed Cobalt) combined with video and
sound and distribute them as files, rather than as part of the image.

With a safe web plugin, you could have a squeaktube site (hmmm better
name needed?) for streaming educational stuff.

Lawson

On 25 March 2010 21:05, Bert Freudenberg <[hidden email]> wrote:

>
> Plus, Alien is newer, so must be better.
>

:)

> - Bert -

--
Best regards,
Igor Stasenko AKA sig.

On Mon, 2010-03-22 at 23:04 -0700, Andreas Raab wrote: I have a couple of questions about this.

First, I thought a lot of the OGL in squeak code required a special vm
to understand a C style syntax for function calls.  So how can this
work?  Possibilities:
  1) 4.1 requires a new VM, and that VM has the feature enabled
  2) existing squeak VM's support it
  3) Croquet code uses that syntax, but it's not in the image.  ogl
calls should be conventional smalltalk style.
  4) ....?

Second, does the later message

> Yeah, I was wondering why it's so much slower in trunk than in our
> internal images or Croquet. First I thought it's the JIT but then I
> looked at a profile and found EventSensor>>wait2ms called from
> several
> places in EventSensor and indirectly via Sensor anyButtonPressed .
imply that performance will be painful?

I'm interested in this partly because Croquet is using lots of CPU when
I try it.  Since I don't need shared spaces, I was hoping something
lighter weight would avoid the problem.  And at least it has a VM with a
known build procedure.

Thanks.
Ross Boylan

On 30.03.2010, at 01:47, Ross Boylan wrote:
No. The VM does not know anything about syntax.

>  So how can this
> work?  Possibilities:
>  1) 4.1 requires a new VM, and that VM has the feature enabled
>  2) existing squeak VM's support it
>  3) Croquet code uses that syntax, but it's not in the image.  ogl
> calls should be conventional smalltalk style.
>  4) ....?

The compiler (which deals with syntax) is written in Smalltalk. You can have any syntax you like. Croquet experimented with this. But it does not have anything to do with the VM.

> Second, does the later message
>
>> Yeah, I was wondering why it's so much slower in trunk than in our
>> internal images or Croquet. First I thought it's the JIT but then I
>> looked at a profile and found EventSensor>>wait2ms called from
>> several
>> places in EventSensor and indirectly via Sensor anyButtonPressed .
> imply that performance will be painful?

No.

> I'm interested in this partly because Croquet is using lots of CPU when
> I try it.  Since I don't need shared spaces, I was hoping something
> lighter weight would avoid the problem.

This is just a raw way to interface with OpenGL. To be really useful you will have to write a 3G engine on top of it.

>  And at least it has a VM with a known build procedure.

Huh?

- Bert -

On 3/29/2010 4:47 PM, Ross Boylan wrote:
> I have a couple of questions about this.
>
> First, I thought a lot of the OGL in squeak code required a special vm
> to understand a C style syntax for function calls.

Both parts are incorrect. First, the OpenGL support doesn't require a
special VM. It requires the Balloon 3D plugin to create a rendering
surface but that's about it.

Second, 'syntax' is something not understood by the VM in general. The
VM executes bytecodes and primitives. Syntax is handled by the Parser in
Squeak. In Croquet, we had indeed special support for non-keyword
method(foo, bar) calls but there is no intrinsic need for that. We're
simply mapping all of these into a consistent set of keyword messages by
prefixing them with the #with: keyword. So the mapping looks like here:

In C                      In Squeak
glGetError()         =>   glGetError
glBegin(mode)        =>   glBegin: mode
glVertex2f(x, y)     =>   glVertex2f: x with: y
glVertex3f(x, y, z)  =>   glVertex3f: x with: y with: z

up until stuff like

glBitmap(w, h, x, y, xm, ym, bm) =>
   glBitmap: w with: h with: x with: y with: xm with: ym with: bm

Croquet always supported the keyword syntax, the non-keyword syntax was
an addition that turned out to be much less useful than we had
originally thought. When I posted the MC package I simply removed all
the non-keyword methods.

> Second, does the later message
>
>> Yeah, I was wondering why it's so much slower in trunk than in our
>> internal images or Croquet. First I thought it's the JIT but then I
>> looked at a profile and found EventSensor>>wait2ms called from
>> several
>> places in EventSensor and indirectly via Sensor anyButtonPressed .
> imply that performance will be painful?

Not at all. Performance is quite good, we still use the same interface
in our products and the actual code is straight out of Cobalt. So on a
basic level the interface has production performance (what you do with
it in your application layer is a different problem of course :-)

The above comment related to the benchmark which was limited by using
Sensor anyButtonPressed in a tight loop - something you'd never do in an
actual product but which is handy for a quick benchmark.

Cheers,
   - Andreas

On Tue, 2010-03-30 at 01:54 +0200, Bert Freudenberg wrote:
> >  And at least it has a VM with a known build procedure.
>
> Huh?
Croquet and Cobalt ship with binary VM, and the procedure used to
generate the VM is undocumented and almost unknown.  By procedure I
don't mean "run VMMaker", but what specific sources and tools were used
to make the VM.

Fairly recent discussion on the cobalt list indicated the build
procedure was in flux.

Thinking the problems I encountered might reflect some library mismatch,
it seemed useful to be able to do the build myself.

Thanks Bert and Andreas for clearing up my misunderstandings about the
opengl for squeak package.

Ross

On 30.03.2010, at 04:34, Ross Boylan wrote:
It's a regular Squeak VM, nothing special. Try it.

There is a tendency to rename the Squeak VM when used for other projects, to make it "easier" for users. OTOH, that practice is creating more confusion for developers. OTTH, one would assume developers to know more than users, so the renamers and duplicaters insist they are right.

At least Linux developers have some sense and do not bundle the VM with the app. A single VM serves all. But then, Linux has built-in dependency management, a luxury that Mac OS and Windows do not have ...

- Bert -

On 2010-03-30, at 2:49 AM, Bert Freudenberg wrote:

> There is a tendency to rename the Squeak VM when used for other projects, to make it "easier" for users. OTOH, that practice is creating more confusion for developers. OTTH, one would assume developers to know more than users, so the renamers and duplicaters insist they are right.

Well the more painful one is when they use the most current macintosh carbon VM, then swap in plugins from the Linux VM that are three or four years old.
--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================

Darn,  tried that with the latest update of Seaside 3.0a.  I had to use
Monticello directly, rather than Installer.   'OpenGL example." returned
the error MessageNotUnderstood: SystemDictionary>>platform



On 3/22/10 11:04 PM, Andreas Raab wrote:

On 5/27/10 7:54 PM, Lawson English wrote:
> Darn,  tried that with the latest update of Seaside 3.0a.  I had to
> use Monticello directly, rather than Installer.   'OpenGL example."
> returned the error MessageNotUnderstood: SystemDictionary>>platform
>
>

Tried again with pristine Seaside 3.0a. Same message.