- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] FileSystem (was: About (backwards) Compatibility)

by Igor Stasenko

a little followup.. Please, do not even try to say that FileDirectory and FileSystem is interchangeable :) Colin laid a foundation in a place where was no foundation at all. Yes, in Pharo we did some changes in order to 'make it work', polishing some rough corners, as well as writing tests and documenting the code. Without laying foundation, nobody starts to build houses.. (well, some do.. but they do not stay long). We even teach kids about that: http://en.wikipedia.org/wiki/Three_Little_Pigs -- Best regards, Igor Stasenko.

Dec. 13, 2012

[Pharo-project] FileSystem (was: About (backwards) Compatibility)

by Igor Stasenko

On 13 December 2012 03:59, Chris Muller <asqueaker(a)gmail.com> wrote: >>> I have no interest in chopping on the great work being done by >>> you and my other friends in Pharo, but that doesn't mean it is >>> feasible for me to use it in my business. While someone in the Pharo >>> community said FileSystem over FileDirectory is "huge", I see it as an >>> incremental API change, and close to being a matter of preference. >>> >> incremental? >> do you think you can implement a memory-based and/or git-based filesystem or >> 'remotely connected database-based file system' >> by just doing incremental changes to FileDirectory? >> good luck with such 'increments' :) > > Yes, of course those capabilities could be added simply with factoring > work and little disruption to the API. That's the promise object > technology, encapsulation. > The main problem with FileDirectory that there's no API. I can hardly call a single class as API... as to me, it is clear that file system domain is a bit more complex and in order to reflect it properly in a language you will need more that a single role (FileDirectory). So, i really doubt that you end up with 'little disruption to API'. It will be substantial. > Colin made a gorgeous domain model of an abstract FileSystem, no doubt > about it. If we switch to it in Squeak I'm sure I will be happy once > the conversion is done. I just think its worth asking, though, > whether a "core" system should provide that rich a model > out-of-the-box or instead just a bland, one-layer-above-the-primitives > lightweight model ready to be easily wrapped by the user's _own_ rich > model of a FileSystem. Is the core system suitable for tiny embedded > programs and will they want a rich model or a basic one? Maybe Spoon > will allow us to have our cake and eat it too..? > To me, design comes first. ALWAYS. All of the rest is secondary. FileSystem establishing a clear separation between conceptual model and implementation detail. The value of such improvement is hard to underestimate: users can learn fast & grasp well how to use it (and even understand better how file systems work). Moreover, it makes FileSystem nicely portable among dialects.. So, in future, if you would like to port your application to another dialect, you'll have to port FileSystem backend, instead of walking over your whole application and do patches all over the place.. Because once you have sound API, an effort to port application gravitates down to zero. Also, porting, in broad sense can mean 'porting from version X to version Y' (speaking about 'backwards compatimilimulability). API establishing a set of rules in a domain & models. The point is that domain does not changes that often, comparing to implementation. That means , if you have a good design, you can be assured that it won't require serious changes and will serve you much much longer without need to change anything in userland code. (Take a Collection protocols for example). Also, once you have such set of rules, it is much easier for people to maintain implementation code, as well as adding extra functionality if needed. Clearly, VM interfaces (such as primitives) should be not exposed to language 'as is', but always come with API. Because if you don't have rules, then you have very poor maintainability inside of system, as well as forcing users to reinvent their own wheel over and over again.. And next thing, if you would want one day to change primitives or change VM.. you will immediately hit the wall, with bloody 'backwards compatibility' sign on it. Because you will discover, that every single application implements own abstraction layer(s) (or even worse, use low-level functionality directly) on top of what you provided. So, to me, your statement looks contradictory: from one side, you are seriously concerned about backwards compatibility, but from another one, you trying to ignore/discard the facts that you cannot have good backwards compatibility without having a design and API in a first place. -- Best regards, Igor Stasenko.

Dec. 13, 2012

Re: [Pharo-project] NativeBoost and Pharo Kernel

by Igor Stasenko

On 12 December 2012 19:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor > > metacello can handle this situation and there is a doc. > We can give a try together. but this is not like we do not have the tool at hand. > yes, i am not saying that it cannot handle.. i just too lazy to spend time reading doc to figure how to do it :) > Stef > > On Dec 11, 2012, at 3:30 PM, Igor Stasenko wrote: > >> On 11 December 2012 09:51, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> Hi, >>> >>> I would like to ask: should NativeBoost be part of the Pharo Kernel? >>> Currently there are some minor issues like that AsmJit-Extension package >>> takes ownership of Integer>>#&, False>>#asBit and so on. >> >> This is because 1.4 don't have those methods, while 2.0. has (added by >> Camillo).. >> and so, currently , NB can either work on both, by making 2.0 image dirty >> or work only in 2.0, and fail to work in 1.4 because of "missing" methods. >> >> I am not very good in metacello-fu to write a confing, which will >> select various set of stuff to load >> depending on image version. >> So, if someone can help, i would appreciate that. >> I can move those methods into NB-pharo-1.4 package.. >> >> >>> Will NativeBoost be >>> more closely integrated with the kernel in the near future? >>> >> depends on what you putting into "kernel". >> if it is "a basic functionality, which is absolutely required to do >> anything else", >> then no, it will be never part of a kernel. >> >> if it is " a set of functionality, ready to use for most common/daily >> tasks" , then yes >> it should be part of such kernel.. >> >> >>> BTW, we need to integrate >>> http://code.google.com/p/pharo/issues/detail?id=7062 before any update that >>> will move methods between packages. >>> >>> Cheers, >>> -- Pavel >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Dec. 13, 2012

[Pharo-project] FileSystem (was: About (backwards) Compatibility)

by Chris Muller

>> I have no interest in chopping on the great work being done by >> you and my other friends in Pharo, but that doesn't mean it is >> feasible for me to use it in my business. While someone in the Pharo >> community said FileSystem over FileDirectory is "huge", I see it as an >> incremental API change, and close to being a matter of preference. >> > incremental? > do you think you can implement a memory-based and/or git-based filesystem or > 'remotely connected database-based file system' > by just doing incremental changes to FileDirectory? > good luck with such 'increments' :) Yes, of course those capabilities could be added simply with factoring work and little disruption to the API. That's the promise object technology, encapsulation. Colin made a gorgeous domain model of an abstract FileSystem, no doubt about it. If we switch to it in Squeak I'm sure I will be happy once the conversion is done. I just think its worth asking, though, whether a "core" system should provide that rich a model out-of-the-box or instead just a bland, one-layer-above-the-primitives lightweight model ready to be easily wrapped by the user's _own_ rich model of a FileSystem. Is the core system suitable for tiny embedded programs and will they want a rich model or a basic one? Maybe Spoon will allow us to have our cake and eat it too..?

Dec. 13, 2012

Re: [Pharo-project] NativeBoost and Pharo Kernel

by Igor Stasenko

On 11 December 2012 20:26, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Igor Stasenko wrote >> I am not very good in metacello-fu to write a confing, which will >> select various set of stuff to load >> depending on image version. >> So, if someone can help, i would appreciate that. >> I can move those methods into NB-pharo-1.4 package.. >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > Where is the NB config kept? I could take a look this weekend. > on sqs/NativeBoost > > > -- > View this message in context: http://forum.world.st/NativeBoost-and-Pharo-Kernel-tp4658786p4658896.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Dec. 13, 2012

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

by Igor Stasenko

On 12 December 2012 22:45, Chris Muller <ma.chris.m(a)gmail.com> wrote: > Hi Stef, I think Pharo is really neat. I have nothing against it > except for the "we are cool, you are not" attitude which I perceive at > times. hehe.. it is natural for people to contrast on something what everyone else knows. and taking in mind the bias .. > I have no interest in chopping on the great work being done by > you and my other friends in Pharo, but that doesn't mean it is > feasible for me to use it in my business. While someone in the Pharo > community said FileSystem over FileDirectory is "huge", I see it as an > incremental API change, and close to being a matter of preference. > incremental? do you think you can implement a memory-based and/or git-based filesystem or 'remotely connected database-based file system' by just doing incremental changes to FileDirectory? good luck with such 'increments' :) >> Now just out of curiosity do you use Pharo ;D > > I do not use Pharo anymore. I tried for a while but the IDE was > difficult for me to work in and there was no reward for constant > patching of my packages just to stay working. I saw how decisions > which can have significant repercussions on low-level parts of the > code-base are made with such little debate. I have business to run > myself, this approach is untenable for me. Squeak's philosophy fits > me just right. > Yes, i agree that people should discuss low-level 'repercussions' and their impact before introducing them, or at least advocate the changes properly with all details and 'why-s'. (personally, i doing that way it all the time) > I will be watching Pharo with great interest. If it settles down > someday, and I need to start up a brand new Smalltalk project which > has no need for Magma or Maui, I will give Pharo another look. > > This thread is about the old debate about backward-compatibility, my > position should not be surprising. > > On Wed, Dec 12, 2012 at 12:22 PM, StÃ©phane Ducasse > <Stephane.Ducasse(a)inria.fr> wrote: >> Come on, chris. Are you getting nervous, tired, bored? Because we are cool and positive thinking :). >> We are not reinventing the past, believe me - I never saw a objectecentric debugger, a bootstrapped kernel >> and a lot moreâ¦.:) >> >> May be you did not read my FAST Pharo presentation or the ESUG one but we want to get >> more business around Pharo and we are doing it. >> >> In addition we are creating a real company (and probably another in the future) and we are really aware about what is to really getting work done. >> You know Moose is probably one of the most complex Pharo application around. >> Now we do not want to live in a place where each time we open a browser on something we cry. >> Why because at the end it will kill us. If we cannot innovate and go fast with Smalltalk then better >> code in Java or Javascript. >> >> This is why we removed FileDirectory (note that camillo nicely proposed a compat package), systemEventNotifierâ¦. >> >> Esteban could port Pier and Seaside to Pharo 1.4 in a couple of hours. >> We have pier running in 2.0. >> >> Now just out of curiosity do you use Pharo ;D >> >> Stef >> >> >> >>> If my goal is to make my computer work for ME, then I want my >>> development system to maximize my leverage and minimize my effort. >>> Breaking compatibility for cleaner code subverts this, as Hannes said, >>> >>>>> Constant input in maintenance effort is needed. >>> >>> I want to use my time applying Smalltalk to real-world problems, not >>> API changes. >>> >>> A blue-plane innovation is worth breaking backward compatibility, >>> reinventing the past isn't. >>> >>> >>>>> maintaining libraries and maybe compatibility layers are very welcome. >>>>> >>>> Yes, and how did we ever thought we could invent the future with Squeak >>>> when in reality, we could not even change a typo in a comment? >>>> >>>> Marcus >>>> >>>> >>>> >>>> >>> >> > -- Best regards, Igor Stasenko.

Dec. 13, 2012

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

by Igor Stasenko

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

Dec. 13, 2012

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

by Igor Stasenko

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

Dec. 13, 2012

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

by Esteban Lorenzano

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. 12, 2012

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

by adrians

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.

Dec. 12, 2012