December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] another kid born: NBExternalEnumerationType

by Ciprian Teodorov

On Thu, Dec 13, 2012 at 8:47 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 13 December 2012 08:16, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> > wrote: > > > > > > On Thu, Dec 13, 2012 at 3:11 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 13 December 2012 03:08, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > On 11 December 2012 20:33, Ciprian Teodorov < > ciprian.teodorov(a)gmail.com> > >> > wrote: > >> >> Hi guys, > >> >> > >> >> today I have commited to the NativeBoost repository a new core class, > >> >> the > >> >> NBExternalEnumerationType, > >> >> which reifies the enum declarations in C and offers a nice interface > >> >> (especially in terms of debug/inspect). > >> >> > >> >> To use it just subclass the NBExternalEnumeration and add an > #enumDecl > >> >> method to the class side such as: > >> >> > >> >> NBExternalEnumeration subclass: #NBTestEnumeration > >> >> instanceVariableNames: '' > >> >> classVariableNames: '' > >> >> poolDictionaries: '' > >> >> category: 'NativeBoost-Tests' > >> >> > >> >> NBTestEnumeration class>>enumDecl > >> >> ^ {(#AAA -> 1). > >> >> (#BBB -> 2). > >> >> (#CCC -> 3). > >> >> (#DDD -> 2400)} asDictionary > >> >> > >> > just one comment: imo, it would be better to not force users to > >> > remember that they should use > >> > complicated syntax in this method. > >> > > >> > i propose following syntax: > >> > > >> > NBTestEnumeration class>>enumDecl > >> > ^ #( > >> > #AAA 1 > >> > #BBB -> 2 > >> > #CCC -> 3 > >> > #DDD -> 2400 > >> > ) > >> > > >> oops, of course it should be just pairs, e.g.: > >> #( A 1 B 2 C 3) > >> Yep this is a good idea for most cases so I'll integrate it. But there > are > >> those cases where your enum has many items (more than the number of > literals > >> we can have in a method), and I think in those cases having the user > give us > >> a prebuilt dictionary is better. > > and where you see many literals? > #( ..... no matter how many stuff here ... ) > is 1 (single) literal! > .. > (i wonder, why people keep confusing literals in method body versus > stuff in a single literal array :) > > And you don't have to trust my word, you can check it by yourself, > just evaluate: > > | x | > > x := #(A B C). > ^ thisContext method literals size > > versus: > > | x | > x := #(A B C D E F G H I J K L M N). > ^ thisContext method literals size > > > My bet, the other day I was trying to do something like x := {#A. #B. #C. #D .......} which did not work, so I wrongly supposed we will have the same issue with #(A B C D). > >> > >> > then you can have > >> > > >> > NBTestEnumeration class>>initializeEnum > >> > > >> > dict := Dictionary newFromPairs: self enumDecl > >> > ..... > >> > > >> > then #initialize should just do 'self initializeEnum' > >> > > >> > > >> > > >> >> DO NOT FORGET to call the #initialize method on your class. The rest > is > >> >> automatically done ;) > >> >> > >> >> You can use your new enum in two ways: > >> >> > >> >> add it to a client class poolDictionaries list (see > >> >> #NBExternalEnumTests > >> >> for an example), and then just write CCC in your code -- CCC here is > an > >> >> item > >> >> of your enum > >> >> or you can send the name of an item to your class --- > NBTestEnumeration > >> >> DDD > >> >> > >> >> The NBExternalEnumeration implements (instance and class) some more > >> >> API > >> >> methods like: > >> >> > >> >> #itemAt: retrieves the item having a specific value --- > >> >> NBTestEnumeration > >> >> itemAt: 2 > >> >> #includes: checks the existence of a specific item in the enum --- > >> >> NBTestEnumeration includes: #AAA > >> >> > >> >> Having this already gives us a nice interface to working with enums. > >> >> Now I > >> >> plan to improve a little bit on performance and usage scenarios: > >> >> > >> >> the possibility to accept smalltalk integers as valid input/output > for > >> >> functions(or callbacks) that use enums as arguments/return. > >> >> support the different representation types for the enum values > >> >> (int/uint) > >> >> > >> > > >> > to my thinking, it not worth implementing separate type converter for > >> > enums.. > >> > just put a note that if people would like to deal nicely with enums > >> > returned by function(s), > >> > they should use a converter , something like that: > >> > > >> > enumValue := MyEnumeration fromInteger: (self > >> > callSomeFunctionReturningInt) > > > > This is a good idea too. > >> > >> > > >> > then this method can implement converting from int->enum object, > >> > as well as do a range checking etc. > >> > in same way, if people want to use 'enumValue' for passing it as > >> > parameter to external function, > >> > they should not pass it directly , but use 'enumValue value' > >> > > >> > In general, it would be cool to have good 'enum type' converter.. > >> > (despite that i will never use it, > >> > because to my taste its not really worth it, and i can live with > >> > integers and in most cases you hide such low-level details from > >> > end-user anyways ;)) > >> > but for those, who want more clarity and better structure in their > >> > code, of course, they can use it . > >> > > > > > I do not completely agree with you on this one (but you already now it). > The > > thing is that if we use integers then the user will have to constantly > ask > > which enum value should I pass here... > > The idea is to not expose enum values to user at all. > Sometimes it easily doable, sometimes not.. it depends , of course.. > But ideally, there should be only messages. > > > If you want that you can always have > > it by declaring your function signature as #(void fct(int anEnumValue)) > and > > then call it with MyEnum DDD value (that's fine). Having an enum type > > converter is very good for documenting the argument types (and > automatically > > checking them). > > True. But everything has its cost: in this case - performance. > > > So I think this should be the user choice. Moreover, I'm for > > incremental development (and learning) so the way I see it is: When you > > first implement the ffi wrapper just try to be as precise as you can be, > > then after your library binding is done you can change some declarations > to > > use more 'low level types' (the underlying representation) for speed > reasons > > mainly (if it ever comes to that). > > > Yes. > > > But at the end I think we should give our users options, which will help > > them make decisions based on their particular needs, not based on our > "gut" > > feeling ;) > > > I agree that this will be nice addition: for better coverage alien (C) > data structures. > I am totally with you on that. > > I just wanted to say that i never thought about it as a necessary part > (simply because > i can live without it). > > -- > Best regards, > Igor Stasenko. > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 13, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Marcus Denker

On Thu, Dec 13, 2012 at 10:40 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 13 December 2012 10:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Now adrian I imagine that you saw that people worked on this bug and this is a rather complex one. >> So I would suggest to you to avoid to draw conclusions too fast. >> > yes, if i remember, we tried to approach it at least once.. > but unfortunately it requires a lot deeper knowledge about bytecode > and (de)optimizations to fix highlight. > I looked at it a bit on the train... With the new infrastructure, we create an intermediate representation which is (nearly) a 1:1 mapping to bytecode (some are mapped to multiple bytecode, multiple IR nodes can result in just one BC), but mostly: 1:1 mapping. The nice thing is that the IRnode records the offset of the bytecode when bytecode is emitted. And the IR knows the AST Node it was created from. And the AST node knows everything (down to the Tokens and the offset in the source text). after adding #instructionForPC: to IRMethod (which just searches for the node), the following code just works: | method astNode| method := Integer>>#+. astNode := (method parseTree ir instructionForPC: 58) sourceNode. method sourceCode copyFrom: astNode debugHighlightStart to: astNode debugHighlightStop returns 'ifTrue: [^ (self digitAdd: aNumber) normalize] ifFalse: [^ self digitSubtract: aNumber]' This needs to be tested and enhanced a bit (e.g. for the case that one IR created multiple bytecodes, e.g. block pre-amble and postscript...). But it should not be that hard to do, I think. The good thing is that it does not rely on some table that is created somewhere, but instead you have the data (IR and AST) directly there to look at. Tweaking special cases should be quite easy with that. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Dec. 13, 2012

Re: [Pharo-project] About (backwards) Compatibility

by StÃ©phane Ducasse

> > I hate to keep repeating myself, but the Pharo manifesto is very clear, and > makes these types of arguments moot: > - Better for the better > - Beauty to learn from > - Not backward compatible > - Clean, lean and fast And we pay attention about change we will not change filesystem every release or announcement. Stef

Dec. 13, 2012

Re: [Pharo-project] who is "dfgs"?

by Camillo Bruni

haha, so these are commits from the pre-full-name aera. Anyway, dfgs was a student in bern ;), but since I put the code in the system I should be the owner ;). VTerm*Driver abstract over the terminal, and yes they are crucial for any decent terminal support. - provide colors for terminal - provide cursor navigation - provide terminal capability access due to lack of NativeBoost in the main image, so far I could not use tcap, but that will change. So far I did not port the input handler (but there is a fully fledged smalltalk-based readline implementation ready). Once that is in the image there should be no more undefined calls. And using #perform: is a very bad habit in my opinion. It breaks all tools, since you make everything implicit (and quite slow as well).. On 2012-12-11, at 09:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > ... and please, please, please, use real names, not initials when committing packages! > > Esteban > > On Dec 11, 2012, at 11:33 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> Hi, >> >> I would like to ask who has the initials "dfgs". And I have a question for him/her. The VTermInputDriver initialization methods generate a lot of unimplemented calls because they expect a handler object with protocol that is not defined in the image. Do we need the VTerm classes at all? Can you provide an abstract handler class? Or what about to switch this calls to perform:/perform:with: form. >> >> Cheers, >> -- Pavel >> >> > >

Dec. 13, 2012

Re: [Pharo-project] Zinc-Resource-Meta-[Core|Tests]

by StÃ©phane Ducasse

I added the entry. stef

Dec. 13, 2012

[Pharo-project] Is the plugin JoystickTabletPlugin of the CogVM package working?

by Carla F. Griggio

Hello! Does anybody know if the JoystickTabletPlugin is actually working for Pharo? I'm trying to use it with CogVM with no success :( I see in InputEventHandler that there is support for pen tablets using this plugin but I can't manage to make it work. As it comes in the CogVM package I assume that somebody put it there because it works, but I keep getting "PrimitiveFailed" error messages wether I have a tablet connected or not. The external plugins of the CogVM are supposed to work without me doing anything? Just executing the VM? Or do I have to activate them somehow? Sorry for keep bothering with this :$ And thanks! Carla.

Dec. 13, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 501 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Dec. 13, 2012

Re: [Pharo-project] How to load Phoseydon and Neptuno?

by Guillermo Polito

Hi! which Pharo version are you using? I was able to download Phoseydon in Pharo 1.4 by doing Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfDBXTools'; load. (((Smalltalk at: #ConfigurationOfDBXTools) perform: #project) perform: #version: with: #stable) load: 'Phoseydon' as it is in the webpage... What problem did you find? BTW, I would move this thread to dbxtalk(a)googlegroups.com or the pharo-users mailing lists. Cheers, Guille On Wed, Dec 12, 2012 at 11:07 PM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > Hi all, is there a working snippet to load these two? I've tried > combinations > from previous threads without success so far. > Thanks, ...Stan > > > > -- > View this message in context: > http://forum.world.st/How-to-load-Phoseydon-and-Neptuno-tp4659102.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Dec. 13, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Igor Stasenko

On 13 December 2012 10:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Now adrian I imagine that you saw that people worked on this bug and this is a rather complex one. > So I would suggest to you to avoid to draw conclusions too fast. > yes, if i remember, we tried to approach it at least once.. but unfortunately it requires a lot deeper knowledge about bytecode and (de)optimizations to fix highlight. > Stef > > On Dec 12, 2012, at 11:28 PM, adrians wrote: > >> >> Well, it just seems that I'm whining here instead of contributing, but if >> the debugger is indeed a very (if not the most) useful tool which is used in >> pretty much every bit of fix-up work, fixing it if it is broken would have >> to come before all else, no? Otherwise, any work that needs to be done until >> it is looked at is just compounded. >> >> Maybe it would make sense to correct (in the current code) to a small degree >> just one of the things that is currently broken. No frills, but just getting >> a more accurate indication of where the PC is - at least have it on the >> correct line of code if it can't be pinpointed more accurately without too >> much hassle. I'm curious what derails the location highlighting as half of >> the time it is close, if not correct. Is it blocks that give it a hard time? >> It wouldn't be too bad if other things were going to take a while if you >> could at least keep track of where you were. >> >> If the idea is to wait until a whole big refactoring can be done on this, I >> fear a fully debugger might be another year away. >> >> -- Adrian >> >> >> >> -- >> View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > -- Best regards, Igor Stasenko.

Dec. 13, 2012

Re: [Pharo-project] Fwd: Lua scripting with nativeboost ?

by dimitris chloupis

Î¤he success of Java shows that marketing is all you need to make something popular. Its funny because after web development (html/js/php) , Java is the most hated thing out there. Both are extremely popular :D Even if python has not been embrassed by google and used in behemoth projects like Youtube, I dont think that it would be as remotely as close to being popular as it is today. ________________________________ From: Igor Stasenko <siguctua(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> Sent: Thursday, 13 December 2012, 10:58 Subject: Re: [Pharo-project] Fwd: Lua scripting with nativeboost? On 13 December 2012 09:54, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > > I was ready to disagree , but you do make a valid point. > > Also going down the pharo route you dont offer games only a better language > but also a development enviroment and that is a double win. I am suprised > that pharo is not used heavily for games. > > And no I dont believe sandbox is the reason. Afterall python is very popular > with games too and has no sandbox. indeed, its all about marketing and having 'killer app', and then you wont notice how eagerly new people will jump into bandwagon. -- Best regards, Igor Stasenko.

Dec. 13, 2012