May 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [Pharo-users] Flushing the VM method cache?

by StÃ©phane Ducasse

Begin forwarded message: > From: Joachim Geidel <joachim.geidel(a)onlinehome.de> > Date: May 20, 2010 6:31:51 PM GMT+02:00 > To: <pharo-users(a)lists.gforge.inria.fr> > Subject: [Pharo-users] Flushing the VM method cache? > Reply-To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> > > Hello all, > > The software I am working on generates classes on the fly, and discards > those classes when they are no longer needed. The class library is > cross-platform, i.e. it exists for Dolphin and VisualWorks, and I am > currently porting it to Pharo. > > In Dolphin, it is necessary to flush the VM's method cache after discarding > all the dynamically generated classes, because the method cache holds > references to the classes which prevent them from being garbage collected. > For VisualWorks, I have adopted this, although I am not quite sure if it's > actually needed there. > > In the Pharo 1.0 image, I haven't found a method for flushing the VM's > method cache in one go, there only seems to be Behavior>>flushCache. > > What I would like to know is: > - Does the VM method cache of the Squeak VM hold references to classes which > prevent an obsolete class from being garbage collected? If this is not the > case, I don't need to flush anything. > - If flushing the cache is advisable, is Behavior>>flushCache the only way > to do this? I would have to pick up all the obsolete classes and iterate > over them in that case. > > Thanks in advance! > Joachim Geidel > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

May 20, 2010

Re: [Pharo-project] Need your opinion: What is most appealing form for GL function bindings?

by Schwab,Wilhelm K

Sig, Since you are focusing on the name of the selector, can I conclude that you are using the selector name to make the call? I am not sure I like that (strongly suspect I do not). Dolphin and FFI use a pragma(-ish??) syntax with the return type, function name and argument types explicitly listed. I very much would like to see you handle the details of getting things on and off of the stack, but I would like to control the selector name and the types. As an example, calling something waveletTransformForward:comma:comma: is not nearly as helpful to me as waveletTransformForward:size:flag: The selector can be even more informative than that, but hopefully it starts to make the case for the independent selector. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, May 20, 2010 10:48 AM To: The general-purpose Squeak developers list; Pharo Development Subject: [Pharo-project] Need your opinion: What is most appealing form for GL function bindings? There are multiple GL bindings exists by now - one that used by Croquet (FFI) - another one that using Alien and i doing one more, which using NativeBoost for callouts. And the question, what form of selectors you like most, pros/cons .. i need to know, because i can pick any of them, but i hope, that i will not be only one who using this stuff, so i need your opinion. Lets take a usual OpenGL function: void glVertex3f(GLfloat x, GLfloat y, GLfloat z) A Croquet/FFI bindings translates it to a following selector: 1. glVertex3f: x with: y with: z An Alien bindings using following form: 2. glVertex3fX: x y: y z: z Since my bindings will definitely use underscores, its not a problem to use a following one: 3. glVertex3f_x: x y: y z: z Currently i using this one: 4. glVertex3f: x y: y z: z In private mail with Andreas, he proposed a following: --- The one thing I'd consider is to use #comma: as the 'standard' keyword instead of #with: for example: 5. glVertex3f: x comma: y comma: z The reason should be obvious; you're replacing the comma so it should be a little more clear than using #with:. --- 6. this option actually not about positional arguments, but about omitting the 'gl' prefix for each function name. It is because, you already typing gl at each invocation: gl glVertex3f: x with: y with: z so, maybe it worth to omit gl prefix, so, a code will look like: gl Vertex3f: x with: y with: z (sure thing, one may use different name for api interface object, not 'gl'.. but i think that in 99.9% cases, 'gl' is a natural choice). --- My own choice is [3]. As to me, it helps greatly when you coding, so, once you autocomplete the selector, you know what parameter you need at each position, unlike anonymous keywords, like with: or comma: , which don't telling you anything about arguments you end up browsing docs each time. Oh, and btw, each time you need to change something, you again may need to refer to docs, since it still may be not clear, what argument types a function expects even if you look at already working code. The pro for picking [1] is mainly be compatible with lots of Croquet code which using GL. Except that, in NB bindings, i taking a constant names as is , i.e. GL_LINES, while croquet uses GLLines. So, its still will require porting. P.S. i'm already having some stuff working (see attachment).. But i little bit hesistant to do more, because then , if i reconsider about selector names, it will require a lot of fixes all around places. It generating all these methods automatically, so i can change a form at any moment. NBOpenGL methodDict size 2063 NBWgl methodDict size 132 NBGlx methodDict size 121 -- Best regards, Igor Stasenko AKA sig.

May 20, 2010

Re: [Pharo-project] Fwd: [Pharo-users] Accentuate Characters

by Mariano Martinez Peck

2010/5/20 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > On May 20, 2010, at 2:18 57PM, Mariano Martinez Peck wrote: > > > > ---------- Forwarded message ---------- > From: Adrien BARREAU <abarreau.dev(a)live.fr> > Date: Mon, May 17, 2010 at 11:16 AM > Subject: [Pharo-users] Accentuate Characters > To: pharo-users(a)lists.gforge.inria.fr > > > Hello, > > I want to compose accentuate character in Pharo, but I don't know how I can > do that. > I saw in Visual Works I can write this kind of things : > > $e composeDiacritical: (Character diacriticalNamed: #acute). > > That returns $Ã©. > > But, I don't find a way to do that in Pharo. > > Does somebody have an idea ? :) > > A.B. > > > cc := CombinedChar new. > cc add: $e; add: (Unicode value: 769); combined > > Diacriticals in CombinedChar only contain the Unicode Combining Diacritical > Marks, it seems. > There's no symbol -> diacriticial char mapping as far as I can tell. > > Cheers, > Henry > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 20, 2010

Re: [Pharo-project] Community Development (a suggestion)

by Sean P. DeNigris

Yanni Chiu wrote: > > I don't think using global write is the right way to fix the problem. > Why not? What is the concrete negative scenario that it creates? There are currently many projects that have this setup, and of course it would be up to each admin. Has anybody out there experienced problems with r/w repos that caused them to change to read-only? That would make a case for caution. Yanni Chiu wrote: > > How about a SqS usage policy: > - the project admin(s) are responsible for keeping their email contact > up-to date > - periodically (monthly?), project admins are ping'ed. If no > acknowledgement is received after three attempts, then the project admin > reverts to the community > - any community member can then ask to become the project admin > I like this as an addition, but it doesn't solve the primary issue of making it easy for people to contribute. I know that currently, every time I go through the process of contacting someone to apply changes, I think, "this is too hard." I'm sure that many fixes out there are lost because of the private development model. How about this: * As you suggest above: projects revert to community after x time * there is an inbox-like place for every project (or one for all external projects), where community contributions can go. This way, the latest code is always available, and it is separate from the owners code Sean -- View this message in context: http://forum.world.st/Community-Development-a-suggestion-tp2224670p2224980.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 20, 2010

Re: [Pharo-project] Pharo sprint this Saturday

by Alexandre Bergel

Well spotted. Thanks Alexandre On 20 May 2010, at 05:38, Oscar Nierstrasz wrote: > > The page says "Sprint Saturday 22, 2010". > > Maybe it would be good to make a note of the month as well, just for the record, > > - on > > On May 20, 2010, at 1:00 , Alexandre Bergel wrote: > >> Yep. If I am not wrong, then >> Time: 9:30 - 21:30 (GMT + 4). For European who wish to follow it via IRC or Twitter, it will begin at 14:30 (GMT +1) in Europe. >> >> Alexandre >> >> >> On 19 May 2010, at 03:41, Serge Stinckwich wrote: >> >>> On Wed, May 19, 2010 at 6:15 AM, Alexandre Bergel >>> <alexandre.bergel(a)inria.fr> wrote: >>>> Hi All, >>>> >>>> I am now with Mariano, working on the details for this Saturday. >>>> More info on http://code.google.com/p/pharo/wiki/PharoSprints >>>> Please, get in touch with Mariano first if you want to attend. >>>> >>>> As already said, the objective of the sprint will be to help produce Pharo 1.1 >>>> >>>> We will try to be present on IRC and/or iChat for remote pair programming :-) >>> >>> Hi Alex, >>> >>> maybe you could add the GMT time of the sprint if some people want to join. >>> >>> Regards, >>> -- >>> Serge Stinckwich >>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >>> Every DSL ends up being Smalltalk >>> http://doesnotunderstand.org/ >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 20, 2010

Re: [Pharo-project] Towards clean unloading Morphic (an idea)

by Andreas Raab

On 5/20/2010 2:47 AM, Igor Stasenko wrote: > Then we can make an easy transition > 1. add this pool to classes which using that global& recompile them > > 2. for classes, which should have no dependency from Morphic, > use a messages like > > Object>> currentWorld > ^ (Smalltalk at: #MorphicPool ifAbsent: [ self error: 'bummer' ]) > currentWorld . I think that's the wrong way to deal with the problem. A polymorphic implementation via Project works much better, i.e., Object>>currentWorld ^Project current world and then Project>>world "No worlds here" ^nil MorphicProject>>world ^world etc. Then you don't need any globals at all. > Then, i hope, you can unload the Morphic using MC and it will leave no > trace in an image (or at least less trace than usual ;). > > Same could be applied to Graphics package (to get rid a Display global) And the same applies. The pattern should be "Project current display". Cheers, - Andreas

May 20, 2010

Re: [Pharo-project] Community Development (a suggestion)

by Yanni Chiu

Sean P. DeNigris wrote: > Since there is a major push in both Squeak and Pharo to be clear about what's > loading where, and get more and more projects loadable; and the community is > fixing projects that we don't own... > > I propose: > 1. Everyone make your SqS repos globally writable unless you have a reason > not to. > 2. SqS admins, send an email to all the repo admins requesting this. I don't think using global write is the right way to fix the problem. How about a SqS usage policy: - the project admin(s) are responsible for keeping their email contact up-to date - periodically (monthly?), project admins are ping'ed. If no acknowledgement is received after three attempts, then the project admin reverts to the community - any community member can then ask to become the project admin This solution wouldn't get you a fast response, but would guarantee you an eventual response. And, the project admins will still be in charge, which is as it should be, IMO.

May 20, 2010

Re: [Pharo-project] Remove developing with Pharo

by Andrei Stebakov

I created a chapter called "Remote Development" under the "Tips and Tricks" chapter. Here is the link: http://book.pharo-project.org/book/TipsAndTricks/RemoteDevelopment/?_s=q1YO… 2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com> > Andrei: Once you have finished to make it work and how to tune it to make > it faster, it would be great if you can write this in a section/chaper of > the collaborative pharo book: http://book.pharo-project.org/ > > If you want I can creat you a user, and the section...then you only need to > write ;) > > > cheers > > mariano > > 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com> > >> Ok, I figured it out. >> On the remote machine just start pharo with RFBServer started (connection >> passwords must be set!) >> On the local Windows machine open ssh or putty tunneling local port 5900 >> to the remote port 5900 (putty -L 5900:localhost:5900 username(a)doman.com >> ). >> After that start a VNC client (in my case I installed TightVNC) and >> connect to your local machine. >> That will automatically establish a tunneled traffic between those two >> systems va ssh tunneling. >> >> >> 2010/5/14 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >> I paste a text I got from an old mail: "The latest version on >>> squeaksource works. You can load it from http://squeaksource.com/RFB(Note that this package has been forked at least three times.) We used to >>> connect to the server with RealVNC with the following settings: ZRLE >>> encoding (disable auto select), Full color. IIRC you should also turn >>> off the "render cursor locally" feature. >>> On the server you should allow ZRLE and turn off the conserve memory >>> feature. >>> " >>> >>> In addition, ask in seaside mailing list too. You will probably receive >>> more help. >>> >>> Cheers >>> >>> Mariano >>> >>> >>> >>> 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com> >>> >>>> Exactly what VNC slient I can use on Windows? >>>> I tried VNC viewer free ( >>>> http://www.realvnc.com/products/free/4.1/winvncviewer.html) trying to >>>> connect to the locally run Pharo and the viewer fails with "uncknown rect >>>> encoding" after which Pharo image also freezes. >>>> Is there any step-by-step tutorial how to setup VNC (remote Linux, local >>>> Windows)? >>>> >>>> >>>> On Thu, May 13, 2010 at 6:26 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>> >>>>> 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com>: >>>>> > Interesting! Is it done on the X-server side or client? >>>>> > >>>>> you should have settings in your VNC client. >>>>> also, you could set bpp for image. >>>>> both could help to run things faster. >>>>> >>>>> > On Thu, May 13, 2010 at 5:38 PM, Igor Stasenko <siguctua(a)gmail.com> >>>>> wrote: >>>>> >> >>>>> >> 2010/5/12 Andrei Stebakov <lispercat(a)gmail.com>: >>>>> >> > That's right, looks like it sends full-blown images (not the >>>>> delta, not >>>>> >> > the >>>>> >> > commands to x-server) and re-drawing takes forever. I wonder if >>>>> it's a >>>>> >> > Pharo >>>>> >> > issue or x-server's? My xterm works pretty fast compared to Pharo >>>>> >> > though... >>>>> >> > >>>>> >> lowering the pixel depth to 8bpp helps :) >>>>> >> >>>>> >> > 2010/5/12 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >>>>> >> >> >>>>> >> >> I have at times done what you are attempting, and painful is >>>>> nicest >>>>> >> >> adjective I can think to use. Please let us know if VNC is a >>>>> better >>>>> >> >> option. Re RDP, I have wondered whether the poor performance >>>>> could be >>>>> >> >> telling us something about the amount of drawing that might be >>>>> >> >> happening for >>>>> >> >> no purpose??? It can be terribly slow, especially the response >>>>> to >>>>> >> >> typing. >>>>> >> >> Bill >>>>> >> >> >>>>> >> >> ________________________________ >>>>> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>>> >> >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf >>>>> Of >>>>> >> >> Mariano >>>>> >> >> Martinez Peck >>>>> >> >> Sent: Wednesday, May 12, 2010 10:25 AM >>>>> >> >> To: Pharo-project(a)lists.gforge.inria.fr >>>>> >> >> Subject: Re: [Pharo-project] Remove developing with Pharo >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> 2010/5/12 Andrei Stebakov <lispercat(a)gmail.com> >>>>> >> >>> >>>>> >> >>> Currently I have my web applications running on a Ubuntu box to >>>>> which >>>>> >> >>> I >>>>> >> >>> connect from a remote WinXP system via ssh. >>>>> >> >> >>>>> >> >> I guess the subject should be "remote" instead of "remove" ? ;) >>>>> >> >> >>>>> >> >> Sorry I ask but why not you cannot just develop in your pc and >>>>> with scp >>>>> >> >> or >>>>> >> >> similar you copy the .image and .image file trough ssh to the >>>>> server ? >>>>> >> >> >>>>> >> >>> >>>>> >> >>> My current set of tools is Lisp/Slime/Emacs. >>>>> >> >>> I tried to launch Pharo with X11 forwarding using X-server on >>>>> WinXP, >>>>> >> >>> but >>>>> >> >>> it painfully slow (the Pharo main windows redraws in a few >>>>> minutes). >>>>> >> >>> I am really thinking developing some web app using Pharo/Seaside >>>>> (I am >>>>> >> >>> liking the language more and more!) but I need to know to do it >>>>> >> >>> remotely via >>>>> >> >>> a secure connection. >>>>> >> >> >>>>> >> >> >>>>> >> >> Yes, there is an implementation of the VNC protocolol. You can >>>>> take a >>>>> >> >> Pharo image and load a VNC server. Then, you can connect to any >>>>> VNC >>>>> >> >> client >>>>> >> >> and what you see is the image....Then you can do whatever you >>>>> want. I >>>>> >> >> don't >>>>> >> >> know the performance, thus. >>>>> >> >> >>>>> >> >> That package is called RFB (remote something buffer) >>>>> >> >> >>>>> >> >> http://book.seaside.st/book/advanced/deployment/maintaining/vnc >>>>> >> >> >>>>> >> >> To install it: >>>>> >> >> >>>>> >> >> Gofer it >>>>> >> >> squeaksource: 'MetacelloRepository'; >>>>> >> >> package: 'ConfigurationOfRFB'; >>>>> >> >> load. >>>>> >> >> ((Smalltalk at: #ConfigurationOfRFB) project perform: >>>>> #latestVersion) >>>>> >> >> load. >>>>> >> >> >>>>> >> >> >>>>> >> >> Cheers >>>>> >> >> >>>>> >> >> Mariano >>>>> >> >> >>>>> >> >> >>>>> >> >>> >>>>> >> >>> Thank you, >>>>> >> >>> Andrei >>>>> >> >>> >>>>> >> >>> _______________________________________________ >>>>> >> >>> Pharo-project mailing list >>>>> >> >>> Pharo-project(a)lists.gforge.inria.fr >>>>> >> >>> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >> >> >>>>> >> >> >>>>> >> >> _______________________________________________ >>>>> >> >> Pharo-project mailing list >>>>> >> >> Pharo-project(a)lists.gforge.inria.fr >>>>> >> >> >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >> > >>>>> >> > >>>>> >> > _______________________________________________ >>>>> >> > Pharo-project mailing list >>>>> >> > Pharo-project(a)lists.gforge.inria.fr >>>>> >> > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >> > >>>>> >> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> Best regards, >>>>> >> Igor Stasenko AKA sig. >>>>> >> >>>>> >> _______________________________________________ >>>>> >> Pharo-project mailing list >>>>> >> Pharo-project(a)lists.gforge.inria.fr >>>>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> > >>>>> > _______________________________________________ >>>>> > Pharo-project mailing list >>>>> > Pharo-project(a)lists.gforge.inria.fr >>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 20, 2010

Re: [Pharo-project] [squeak-dev] [BUG] LiteralVariableNode>>sizeCodeForStorePop:

by Eliot Miranda

Oops. Find fix attached: LiteralVariableNode methods for code generation (new scheme) sizeCodeForStorePop: encoder self reserve: encoder. ^(key isVariableBinding and: [key isSpecialWriteBinding]) ifTrue: [(self sizeCodeForStore: encoder) + encoder sizePop] ifFalse: [encoder sizeStorePopLiteralVar: index] Arguably the compiler should issue an error, but the error is raised at run-time because the generated code sends value: (correct) rather than using any of the store lit var bytecodes. If a compiler error is wanted (my preference) then find attached: LiteralVariableNode methods for testing assignmentCheck: encoder at: location ^(key isVariableBinding and: [key isSpecialWriteBinding]) ifTrue: [location] ifFalse: [-1] On Thu, May 20, 2010 at 2:16 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Open a browser, pick any class, and enter the code: > > foo > WorldState := nil > > then accept it. > The compiler goes into an infinite recursion in > LiteralVariableNode>>sizeCodeForStorePop:. > > sizeCodeForStorePop: encoder > self reserve: encoder. > ^(key isVariableBinding and: [key isSpecialWriteBinding]) > ifTrue: [(self sizeCodeForStorePop: encoder) + encoder > sizePop] > ifFalse: [encoder sizeStorePopLiteralVar: index] > > > (Pharo 1.1 having no such problem - it accepts a code without any > warnings.. ) > > AFAIK, it should either warn or throw an error that assignment is not > possible into read-only variable binding. > > -- > Best regards, > Igor Stasenko AKA sig. > >

May 20, 2010

[Pharo-project] Need your opinion: What is most appealing form for GL function bindings?

by Igor Stasenko

There are multiple GL bindings exists by now - one that used by Croquet (FFI) - another one that using Alien and i doing one more, which using NativeBoost for callouts. And the question, what form of selectors you like most, pros/cons .. i need to know, because i can pick any of them, but i hope, that i will not be only one who using this stuff, so i need your opinion. Lets take a usual OpenGL function: void glVertex3f(GLfloat x, GLfloat y, GLfloat z) A Croquet/FFI bindings translates it to a following selector: 1. glVertex3f: x with: y with: z An Alien bindings using following form: 2. glVertex3fX: x y: y z: z Since my bindings will definitely use underscores, its not a problem to use a following one: 3. glVertex3f_x: x y: y z: z Currently i using this one: 4. glVertex3f: x y: y z: z In private mail with Andreas, he proposed a following: --- The one thing I'd consider is to use #comma: as the 'standard' keyword instead of #with: for example: 5. glVertex3f: x comma: y comma: z The reason should be obvious; you're replacing the comma so it should be a little more clear than using #with:. --- 6. this option actually not about positional arguments, but about omitting the 'gl' prefix for each function name. It is because, you already typing gl at each invocation: gl glVertex3f: x with: y with: z so, maybe it worth to omit gl prefix, so, a code will look like: gl Vertex3f: x with: y with: z (sure thing, one may use different name for api interface object, not 'gl'.. but i think that in 99.9% cases, 'gl' is a natural choice). --- My own choice is [3]. As to me, it helps greatly when you coding, so, once you autocomplete the selector, you know what parameter you need at each position, unlike anonymous keywords, like with: or comma: , which don't telling you anything about arguments you end up browsing docs each time. Oh, and btw, each time you need to change something, you again may need to refer to docs, since it still may be not clear, what argument types a function expects even if you look at already working code. The pro for picking [1] is mainly be compatible with lots of Croquet code which using GL. Except that, in NB bindings, i taking a constant names as is , i.e. GL_LINES, while croquet uses GLLines. So, its still will require porting. P.S. i'm already having some stuff working (see attachment).. But i little bit hesistant to do more, because then , if i reconsider about selector names, it will require a lot of fixes all around places. It generating all these methods automatically, so i can change a form at any moment. NBOpenGL methodDict size 2063 NBWgl methodDict size 132 NBGlx methodDict size 121 -- Best regards, Igor Stasenko AKA sig.

May 20, 2010