- Pharo-dev - lists.pharo.org

[Pharo-project] Spec question: menues
by Torsten Bergmann Nov. 29, 2012

Nov. 29, 2012

Can anyone point me to a spec example with a (context) menu with icons and where we can enable/disable specific menue items depending on state?

3 4

[Pharo-project] Internship
by Goubier Thierry Nov. 29, 2012

Nov. 29, 2012

Hi all, I'm looking for some help in parsing C files (and the opportunity to use Petit Parser (Parseur?)) so I'm looking for an internship candidate (Master level). The objective is to do a C preprocessor with a targeted integration in an existing C parser, and, in particular, provide high-level information about applied macros/defines for the tokens provided to the C parser itself. Platform should be Pharo (2.0:)). Place is Saclay, SW of Paris. The lab has a strong team on compilation tool chains for embedded manycores, from programming language design down to micro-kernel and mapping, and is able to select good interns for further work opportunities. http://www.cea.fr/ressources-humaines/stages-et-formation-en-alternance/les… Regards, Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

3 6

[Pharo-project] [update 2.0] #20422
by Marcus Denker Nov. 29, 2012

Nov. 29, 2012

20422 ----- Issue 7069: Better pop up menu entries http://code.google.com/p/pharo/issues/detail?id=7069 Issue 7068: Fixed smartCharacter http://code.google.com/p/pharo/issues/detail?id=7068 Issue 7066: Hot-Fix for MC version serializer http://code.google.com/p/pharo/issues/detail?id=7066 Diff information: http://ss3.gemstone.com/ss/Pharo20/NECompletion-MarcusDenker.68.diff http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.729.diff http://ss3.gemstone.com/ss/Pharo20/Compiler-MarcusDenker.362.diff -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

1 0

[Pharo-project] Alt-. does not work anymore on Linux or?
by Torsten Bergmann Nov. 29, 2012

Nov. 29, 2012

Same issue with Stack VM. So it looks like it is image side. When the keyboard focus is in a workspace and I hit CMD+. it not directly interrupts. Only when I repeat very often. I've put a Transcript show: toInterrupt asString; cr. into UserInterruptHandler>>handleUserInterrupt and very often this block temporary variable is nil since #processToInterrupt returns nil. Sometimes the #processToInterrupt catches a process to interrupt and then the debugger opens. GÃ¶ran can you confirm that as well? Bye T.

2 2

[Pharo-project] Alt-. does not work anymore on Linux or?
by Torsten Bergmann Nov. 29, 2012

Nov. 29, 2012

On Win32 (german locale) I can not interrupt (Delay forSeconds: 10) wait. 1 inspect when using NBCog.exe as a VM. Even when I set a new key like ";" (without ALT) I can not interrupt the delay. |handler| handler := UserInterruptHandler new setInterruptKeyValue: ($; asciiValue). handler registerIn: InputEventFetcher default. (Delay forSeconds: 10) wait. 1 inspect I can not interrupt with ";" while the delay is waiting. But it interrupts aftewards when I hit ";". I'm not sure it is really a locale problem as described in http://code.google.com/p/pharo/issues/detail?id=6688 When I try 1.4 one click I have the same problem - the delay is not interruptable. When I try 1.3 one click I can interrupt. Can it be related to switching to Cog VM starting from 1.4? Bye T.

2 1

[Pharo-project] Alt-. does not work anymore on Linux or?
by Torsten Bergmann Nov. 29, 2012

Nov. 29, 2012

It's not a Linux issue. When I run (Delay forSeconds: 5) wait on Win32 with Pharo 2.0 I can also not interrupt it using ALT+. I checked and "UserInterruptHandler cmdDotEnabled" returns true in my image. Havent digged deeper. Can you please open an issue? Thx T.

2 1

[Pharo-project] NativeBoost extending Object
by Ciprian Teodorov Nov. 29, 2012

Nov. 29, 2012

Hi guys, Looking at NB methods extending Object I am wandering if it won't be better to put them in a Trait to be used by any class needing them? As for ByteArray maybe instead of using the methods inherited from Object maybe we can use a double-dispatch scheme to delegate NB calls to another class. This way we won't need to extend Object anymore... Igor, what do you think? (if you agree I will do it for NB)... I don't know if that will play well with existing NB-based projects though (Athens, NBOpenGL, etc...) But I think it is worth it on the long run... Cheers, -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

4 11

[Pharo-project] NativeBoost extending Object
by Igor Stasenko Nov. 29, 2012

Nov. 29, 2012

On 29 November 2012 08:29, Torsten Bergmann <astares(a)gmx.de> wrote: >>and i am not really happy with that. I prefer having 9 methods in Object >than 9*100 methods in many classes. > > What about having just one single method on Object called #externalCaller (or just #external) that returns an object understanding the > callout protocol. > > self externalCaller call: 'whatever' > > This wont overload Object but may require some fiddling since > "thisContext sender" is used. > > ... and this is what new api 'self nbCallout' provides. > > I also dislike the "namespacing" using "nb" in the selectors. > What if you rename or replace the project in the future? > > I would have to rename my methods from ffiCall: to alienCall: > to nbCall: ... ;) > a solution to this problem: use own convenience method(s).. then if you will ever need to get rid of namespace, all you need to do is change few methods. > Yes I know it is a different interface protocol from FFI to > NativeBoost - but still nobody is interested that the > subproject is called FFI/Alien/NativeBoost once it is > integrated in standard Pharo. > > You just want to do an external call like in any other > language and you are just interested that it works > reliable and easy. > > > And I would vote for a simple pragma <externalCall> > instead of > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > Sorry for all the wished ... but Christmas is near ... > did you behave well this year? you know Santa do not likes bad boys :) If serious.. we're evolving.. and it takes time and effort to change skins. Once we will be ready to get rid of namespace prefix, then we can abandon it, but not right now. > BTW: I marked 1.6 as release > 1.7 as stable > 1.8 as new development in the config > > We can also mark 1.7 as release since there was an official > announcement from Igor. Version 1.8 should get new developments. > > Thanks > Torsten -- Best regards, Igor Stasenko.

1 0

[Pharo-project] NativeBoost extending Object
by Torsten Bergmann Nov. 29, 2012

Nov. 29, 2012

>and i am not really happy with that. I prefer having 9 methods in Object >than 9*100 methods in many classes. What about having just one single method on Object called #externalCaller (or just #external) that returns an object understanding the callout protocol. self externalCaller call: 'whatever' This wont overload Object but may require some fiddling since "thisContext sender" is used. I also dislike the "namespacing" using "nb" in the selectors. What if you rename or replace the project in the future? I would have to rename my methods from ffiCall: to alienCall: to nbCall: ... ;) Yes I know it is a different interface protocol from FFI to NativeBoost - but still nobody is interested that the subproject is called FFI/Alien/NativeBoost once it is integrated in standard Pharo. You just want to do an external call like in any other language and you are just interested that it works reliable and easy. And I would vote for a simple pragma <externalCall> instead of <primitive: #primitiveNativeCall module: #NativeBoostPlugin> Sorry for all the wished ... but Christmas is near ... BTW: I marked 1.6 as release 1.7 as stable 1.8 as new development in the config We can also mark 1.7 as release since there was an official announcement from Igor. Version 1.8 should get new developments. Thanks Torsten

1 0

[Pharo-project] NativeBoost - new version new ideas ;)
by Ciprian Teodorov Nov. 29, 2012

Nov. 29, 2012

Hi Igor, While I'm waiting impatiently for the new NB version I played around some more and I have noted some ideas: First thing is related to structures and callbacks... what if I want to have a callback as a member of a structure? It seems to me that the way to go is to declare a MyCallback class and then use it in the structure, which is fair enough. But what if I have a function that initializes this structure with a user provided callback? Then the structure is not printed correctly. It seems that #*coerceReturnValue: is not implemented in the NBCallbackType... * *While this is not a big issue it made me think that I was doing something wrong... Maybe in this case we can instantiate MyCallback class and put the fct pointer in in trunk ivar.* Secondly, related to structs again... It seems that we can define structures like: struct { void *a[2]; } only by transforming them to struct { void *a1; void *a2; } Am I wrong... if not maybe we can extend a little bit the syntax for defining structs to accept the first form... which will be far easier to write if we have large index values like void *x[20]... What do you think? Lastly, seeing that we are starting to have support for most of c-like declarations, i am not really satified with the way the enums should be handled... Maybe we can reify them as some kind of external object so that we can say something like: enum { AAA = 1, BBB = 2, }; MyEnum AAA (to get the item AAA of the enum) MyEnum BBB value = 2 and behind the enumeration is defined as a Dictionary of item->value mappings. Attached to this mail you will find a fileout of such an approach... I agree that maybe this is not the most optimized way of dealing with enums, however I like this approach because it is uniform (with structs, external objects, external addresses, callbacks, etc). Moreover if a beginner wants to hack his way into NB FFI I think it is easier to cope with an enum object than with SharedPools defined in classes, and imported. Cheers, PS: I can't way to get my hand on the new version... -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

2 2