- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

Thanks Sven We will integrated that in 2.0 Stef On Dec 12, 2012, at 9:03 PM, Sven Van Caekenberghe wrote: > Just a quick note: the first version of Zinc-Resource-Meta-[Core|Tests] containing ZnUrl and ZnMimeType independent of / separate from / as a dependency for Zinc-HTTP is now available. > > ConfigurationOfZincHTTPComponents version 2.0 reflects this change (#stable for Pharo 2.x). > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Dec. 13, 2012

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

by StÃ©phane Ducasse

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. Your analysis is right. No this is not the idea. We never waited for big bang. But frankly I invite to come in our team to see us fully busy. Because we are doing far more than Pharo. Stef > > -- 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. >

Dec. 13, 2012

[Pharo-project] I love to see the commit log on OPAL

by StÃ©phane Ducasse

continue this is cool :)

Dec. 13, 2012

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

by Igor Stasenko

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

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

by dimitris chloupis

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. ________________________________ From: Esteban Lorenzano <estebanlm(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: Thursday, 13 December 2012, 1:45 Subject: Re: [Pharo-project] Fwd: Lua scripting with nativeboost? On Dec 12, 2012, at 7:27 PM, Marten Feldtmann <marten(a)schrievkrom.de> wrote: > On 12.12.2012 17:18, Esteban Lorenzano wrote: > >> IMO, that's non-sense. > > Well, that is a matter of view. no, it is not. Is a matter of making a technical choice or a marketing one. You know than while a lot before any scripting language were used in gaming the "common sense" and "marketing choice" was not using anyone because "it was too slow"? if we follow what marketing says, you should do your game in C++ (or even better, plain C) and provide hooks to lua/python/whatever... technically, you lose power by choosing lua (or anything) instead pharo in an application made in pharo. people choice depends much more on the success of the game/app than the platform to make it/create extensions. I can say it not because I have the theoretical tools, I say it because I can see my nephew (9 years old) creating plugins for one game he plays, then just jump to another game and make plugins with another complete different language... what has "the marketing" to do with that? he likes his games, and he like extend them... all the other is "collateral". > I've done this also with Lua and VASmalltalk and I did this not because of other Smalltalkers in mind using my software, but perhaps of potential end users willing to enhance the application in a more known language. potencial users who does not know about programming will feel a lot more comfortable smalltalk than ant algol-based language. > Because of this I also tried to use Rexx as an extension language, which is in my view even more suitable to be used as an embedded language - but the market decided to use Lua and not Rexx. no idea about REXX... but I repeat: if the game is successful, no one cares the plugin language (and lua is not the unique scripting language for gaming around you know that) Esteban > > Marten > <marten.vcf>

Dec. 13, 2012

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

by Igor Stasenko

>> 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. > Just to elaborate a bit, here the real example AthensCairoPaintMode cairo has a function void cairo_set_operator (AthensCairoCanvas canvas, cairo_operator_t aCairoOperatorT) ) to set a composition operator (porter-duff one). The cairo_operator_t is indeed enum there. So, if i would use enums, users would need to tell: canvas setPaintMode: enumValue instead, the syntax to say that is following: canvas paintMode enumValueName in that way i deal with two problems: - users don't have to use shared pools in their code, more than that, it is impossible to pass some invalid value to the function. - since Athens can use multiple backends, using backend-specific enumeration values would immediately render application tightly coupled with specific backend. To avoid that, i would be needing to define own backend-neutral enumeration and then map it to backend-specific one.. This is stinks a lot to my taste.. Instead, a backend-specific AthensPaintMode subclass simply implements own method per each enumValueName for example: overlay ^ self setOperator: CAIRO_OPERATOR_OVERLAY -- Best regards, Igor Stasenko.

Dec. 13, 2012

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

by Igor Stasenko

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 >> >> > 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.

Dec. 13, 2012

[Pharo-project] [update 2.0] #20435

by Marcus Denker

20435 ----- Issue 7120: Make Print It deal better with errors in printString http://code.google.com/p/pharo/issues/detail?id=7120 Issue 7099: Integration of NewList in 2.0 (again) http://code.google.com/p/pharo/issues/detail?id=7099 Issue 7024: unify #compile:classified:withStamp:notifying:logSource: http://code.google.com/p/pharo/issues/detail?id=7024 Diff information: http://ss3.gemstone.com/ss/Pharo20/Traits-MarcusDenker.447.diff http://ss3.gemstone.com/ss/Pharo20/Text-MarcusDenker.46.diff http://ss3.gemstone.com/ss/Pharo20/NewList-MarcusDenker.11.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1306.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1267.diff

Dec. 13, 2012

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

by Ciprian Teodorov

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. > > 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... 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). 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). 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 ;) > > >> So that will be for now. Feel free to try it out and send me any > comments > >> and/or improvement ideas, It will be my pleasure to improve it. > >> 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 > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > -- > 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] About (backwards) Compatibility

by Sean P. DeNigris

Chris Muller-4 wrote > While someone in the Pharo > community said FileSystem over FileDirectory is "huge", I see it as an > incremental API change Can you still say that after reading http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?! FileSystem has hugely decremented the number of times I've wanted to throw my computer at a wall ;) FileDirectory occurred to me like graffiti painted on a great work of art. Multiply the above by every dark corner of the system and you have the barrier to the next stage of evolution. For myself, every time I've embarked on a bold new idea for our IDE, after getting bogged down in a mess of objects - like FileDirectory et al, or Paragraph and friends, or Morphic layout objects, and on and on - I reached a point where I was not willing to put in the tremendous effort required to understand the system (if even possible). And because few of the design decisions are documented, I didn't know how to clean things without breaking them. So, I gave up and just went back to the standard tools. 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 Cheers, Sean -- View this message in context: http://forum.world.st/About-backwards-Compatibility-tp4658784p4659133.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 13, 2012