- Pharo-dev - lists.pharo.org

[Pharo-project] Proper Smalltalk lots of classes

by Jimmie Houchin

Hello, I am porting the FIX protocol to Squeak/Pharo. http://www.fixprotocol.org/ It is the Financial Information eXchange protocol. It is used by many firms in the financial industries, stocks, forex, etc. There is good documentation and also a semi-reference implementation in Java. http://www.quickfixj.org I have a partial port started but I wanted a check with those who know more than I about proper Smalltalk coding. In the Java implementation there are over 2000 classes. In the protocol there are approximately 90 message types and 956 field types. I am initially creating the message classes as they form the basis of the protocol and the fields are simply instance variables and methods in the message classes. I am not porting the Java library. I am implementing the protocol in Smalltalk from the documentation. Initially I have created a Fix44Field class with its necessary variables. There are several versions of the Protocol and FIX 4.4 is the one required for my application. With this Fix44Field class I am creating a Dictionary with the 956 different field types. I am planning on creating a constructor method which will create the desired field from the information in the dictionary about the field and its properties. Am I way off base here? Should I really create the 956 classes necessary to for each field in addition to the 90 or so message classes, and then I don't know what else I haven't discovered yet. Having 1000+ classes just seems unwieldy and naively it just doesn't feel like the Smalltalk way. I could be wrong, but I haven't seen such an example to my memory. I don't know enough about Java to know if it is good Java form either. When I have a reasonably fleshed out, tested and working solution, I will make the source available under a MIT license. I would love to see Squeak/Pharo become an out of the box viable option for trading applications. Advise and wisdom greatly appreciated. Thanks. Jimmie

Dec. 31, 2010

Re: [Pharo-project] new Cog VMs

by Eliot Miranda

ignore this one. I have the patient on the table... On Fri, Dec 31, 2010 at 12:25 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > thanks to everyone finding bug cases. Please keep it up. I'm anxious > to find a reproducible case for a crash in (what I thought was fixed) > bytecode to machine code pc mapping with the r2333 VMs which has a stack > trace like the following: > > Thread 0 Crashed: Dispatch queue: com.apple.main-thread > 0 com.teleplace.Teleplace 0x000b8ca6 mapForbcpcperformUntilarg + > 166 (cogit.c:10929) > 1 com.teleplace.Teleplace 0x000b8f3c mcPCForstartBcpcin + 44 > (cogit.c:11480) > > I get it only intermittently (ironically when pushing out a new version of > the VM sources) and would love to find a reproducible case. So if anyone > sees this I'd be indebted if you could spend some time trying to make it > easily reproducible. > > TIA > Eliot > > On Thu, Dec 30, 2010 at 6:02 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Hi All, >> >> I've released a new version of Cog that has a substantially improved >> code generator along the lines of Peter Deutsch's HPS (VisualWorks) and >> various of Ian Piumarta's VMs. These all use a simple tecnique to identify >> constant references in bytecode and to support a register-based calling >> convention. While this does produce faster code it tends to accelerate >> low-level code much more than high-level code as you can see by the >> following benchmarks: >> >> SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 >> StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 >> 192 - 691 / 6.91 -72% >> >> SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 >> sends/sec' >> StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; >> 128157989 sends/sec' >> 931756141 - 753495217 / 7534952.17 -24% >> 128157989 - 64769127 / 647691.27 -98% >> >> SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no >> transcript >> StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no >> transcript) >> 43406 - 47013 / 470.13 -7.67234594686576 >> >> The status of this code is essentially beta. The test suite runs the same >> on the new code generator as on the old, but I think there are still bugs >> because I get the occasional transient error. I am therefore very >> interested in any reproducible errors you can find. >> >> The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a >> few other important changes: >> >> - a bug fix to bytecode<->native pc mappng that produced incorrect results >> for methods containing blocks with ^-returns in them. One symptom is >> incorrect highlighting of the pc in the debugger, althoguh symptoms could be >> much serious. >> >> - jitting interpreted methods on backward branches. Currently any >> interpreted method that performs more than 20 backward branches will be >> considered for JIT compilation and if it is suitable (default, <= 60 >> literals) will be compiled to native code. >> >> - new callback support. I need to commit some changes to the Alien >> package to provide access to this but essentially the VM's callback support >> is now able to be ported to architectures with register-based calling >> conventions (ARM, PowerPC, SPARC etc). I'll try and get the Alien code >> released soon, and to back-port the changes to the standard VM before the >> end of the holiday. >> >> One thing that is still /not/ fixed is the lack of a SoundPlugin on win32. >> Apologies. I'll try and get a fix for this before the end of the holidays >> too, but time might be too tight. There are other priorities such as >> harmonising the standard and Cog VMs for the 4.2 release. >> >> best >> Eliot >> >> >

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Eliot Miranda

On Fri, Dec 31, 2010 at 11:50 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Oh, come on... > > Levente, we all agree with you. Pharo is trying to use that deprecation > policy since some months ago... Sometimes people make mistakes (me > included) and don't do it, but we agreed that we have to deprecate and > remove after two versions of being deprecated. > > I'm tired of this stupid arguments. > > I expect the new year will bring us more doing and less discussing :). > Unless we are prepared to discuss, discover, admit and correct our mistakes our doing will be of little worth. I don't see anything stupid in discussing deprecation policy. This criticism of Levente is entirely unjustified and reminds me of recent treatment of certain prominent whistle-blowers. Can we just drop the childish feelings of hurt, and direct ourselves to the substance of arguments rather than our immediate emotional reactions to email? We should all know by now that email is a particularly inexpressive medium, prone to misinterpretation and therefore it behooves us to take a breath before we reply and try and read beyond our surface perceptions. [I am a hypocrite in this regard having over-reacted recently over timestamps.] Doubtless we are all imperfect in our use of email and can all do better here. But we won't get any better by lacking objectivity and reacting emotionally to valid criticism. Can we make one of our new year's resolutions an attempt to be less emotional and more objective in all our email discussions in the broader Squeak community? Please? Happy New Year Eliot > > 2010/12/31 Levente Uzonyi <leves(a)elte.hu> > > On Fri, 31 Dec 2010, Miguel CobÃ¡ wrote: >> >> El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribiÃ³: >>> >>>> What you describe here is simply bad practice. One should run the tests >>>> before deploying code (besides testing the complete system thoroughly). >>>> If you use RFB, you can access the GUI in headless mode. Also when a >>>> debugger opens with a deprecation warning, the stack trace is written to >>>> the log file, so you will be notified about the problem even when you >>>> don't have access to the GUI. >>>> >>> >>> Yeah, sure. But if it a second level dependency (a package I use that >>> uses a package that contains popups deprecation warnings) I have big >>> chances of being bite by this problem. I concede, this could be avoided >>> by test-running every and whatnot package in the image but for a system >>> that updates automatically this will bite. >>> >> >> So you're saying that it's better to get a DNU instead of a deprecation >> warning with proper description about what and how to update/change? >> >> >> Levente >> >> >> Also, even if I can use RFB or read the image logs, I most likely will >>> monitor the application logs and will pass a time without me knowing >>> that some part of the application is waiting some user input. >>> At the end I expect that the maintainer of the package is the >>> *responsible* of test the application for the image I use, and not the >>> user of the package. That is what I do with magma on Pharo. I test and >>> fix the issues generated by the evolution of Pharo and then I release a >>> new ConfigurationOfMagma that the user can use without knowing that n >>> deprecations were involved in the upgrade of the package. >>> >>> >>> >>>> Anyway, there's no reason to remove a method (especially an API method) >>>> without deprecating and keeping it around for a few releases. >>>> >>>> >>> I agree that is better to not forget to mark some method as deprecated >>> but, again, I think that this promote the external packages not being >>> updated to the current pharo image. >>> >>> Cheers >>> >>> -- >>> Miguel CobÃ¡ >>> http://twitter.com/MiguelCobaMtz >>> http://miguel.leugim.com.mx >>> >>> >>> >>> >>> >

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Chris Muller

> Of course it is better. A pop up can be in some code path that only > seldom is executed. For someone loading the code, no warnings means that > everything is ok. Suppose they install it on a server side image > thinking that everything is ok. Then sometime after that, the image > stops working because the headless mode can't allow to see the popup > that is waiting for someone to press a button. Again, the GUI is Â good > sometimes, but sometimes is better to fail earlier. > If on loading it doesn't load because of some missing method, the user > can see right there that something is wrong with the package is trying > to use. A robust server will have proper error-handling. I put a check for #maIsHeadless in my error-handler for Warnings so that they'll never halt when headless, but output a line to the log file. With that out of the way, that leaves, "the GUI is good." :) - Chris

Dec. 31, 2010

Re: [Pharo-project] new Cog VMs

by Eliot Miranda

Hi All, thanks to everyone finding bug cases. Please keep it up. I'm anxious to find a reproducible case for a crash in (what I thought was fixed) bytecode to machine code pc mapping with the r2333 VMs which has a stack trace like the following: Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 com.teleplace.Teleplace 0x000b8ca6 mapForbcpcperformUntilarg + 166 (cogit.c:10929) 1 com.teleplace.Teleplace 0x000b8f3c mcPCForstartBcpcin + 44 (cogit.c:11480) I get it only intermittently (ironically when pushing out a new version of the VM sources) and would love to find a reproducible case. So if anyone sees this I'd be indebted if you could spend some time trying to make it easily reproducible. TIA Eliot On Thu, Dec 30, 2010 at 6:02 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > I've released a new version of Cog that has a substantially improved > code generator along the lines of Peter Deutsch's HPS (VisualWorks) and > various of Ian Piumarta's VMs. These all use a simple tecnique to identify > constant references in bytecode and to support a register-based calling > convention. While this does produce faster code it tends to accelerate > low-level code much more than high-level code as you can see by the > following benchmarks: > > SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 > StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 > 192 - 691 / 6.91 -72% > > SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 > sends/sec' > StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; > 128157989 sends/sec' > 931756141 - 753495217 / 7534952.17 -24% > 128157989 - 64769127 / 647691.27 -98% > > SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no > transcript > StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no > transcript) > 43406 - 47013 / 470.13 -7.67234594686576 > > The status of this code is essentially beta. The test suite runs the same > on the new code generator as on the old, but I think there are still bugs > because I get the occasional transient error. I am therefore very > interested in any reproducible errors you can find. > > The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a few > other important changes: > > - a bug fix to bytecode<->native pc mappng that produced incorrect results > for methods containing blocks with ^-returns in them. One symptom is > incorrect highlighting of the pc in the debugger, althoguh symptoms could be > much serious. > > - jitting interpreted methods on backward branches. Currently any > interpreted method that performs more than 20 backward branches will be > considered for JIT compilation and if it is suitable (default, <= 60 > literals) will be compiled to native code. > > - new callback support. I need to commit some changes to the Alien package > to provide access to this but essentially the VM's callback support is now > able to be ported to architectures with register-based calling conventions > (ARM, PowerPC, SPARC etc). I'll try and get the Alien code released soon, > and to back-port the changes to the standard VM before the end of the > holiday. > > One thing that is still /not/ fixed is the lack of a SoundPlugin on win32. > Apologies. I'll try and get a fix for this before the end of the holidays > too, but time might be too tight. There are other priorities such as > harmonising the standard and Cog VMs for the 4.2 release. > > best > Eliot > >

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Igor Stasenko

On 31 December 2010 19:47, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 31 Dec 2010, Igor Stasenko wrote: > >> 2010/12/31 Levente Uzonyi <leves(a)elte.hu>: >>> >>> On Fri, 31 Dec 2010, Igor Stasenko wrote: >>> >>>> ahahaa.. you guys are killing me.. >>>> You are taking things too serious. >>>> Yeah.. i would be gladly hear from Levente, what is 'the proper >>>> deprecation policy'. >>>> But since nobody described it, we are doomed to use one, invented before >>>> :) >>> >>> I described my ideas here, so I won't repeat it. But I can tell you that >>> removing a method which wasn't deprecated at all is _not_ a proper >>> deprecation policy. >>> >> can you give a pointer, where i can read about it? > > You can search this mailing list. But to make it a bit easier, it's > basically the same as what it's intended to be: > - deprecate all non-private methods that are to be removed (some private > methods should also be deprecated) > - keep the deprecated methods for at least one new release > - calculate the deprecation dates from the method timestamps > Forgive me my ignorance. I know that Pharo using a deprecation policy, but i didn't paid much attention to details, and probably missed some key messages where policy was discussed. I knew only that people agreed to not remove methods immediately and that deprecation warning should stay at least single release cycle. -- Best regards, Igor Stasenko AKA sig.

Dec. 31, 2010

Re: [Pharo-project] [Vm-dev] new Cog VMs

by David T. Lewis

On Thu, Dec 30, 2010 at 06:02:36PM -0800, Eliot Miranda wrote: > > Hi All, > > I've released a new version of Cog that has a substantially improved > code generator along the lines of Peter Deutsch's HPS (VisualWorks) and > various of Ian Piumarta's VMs. This is very impressive - thank you! Dave

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Miguel CobÃ¡

El vie, 31-12-2010 a las 20:38 +0100, Levente Uzonyi escribiÃ³: > So you're saying that it's better to get a DNU instead of a deprecation > warning with proper description about what and how to update/change? > No. I say that is the job of the maintainer of the package (or the upstream developer) to ensure some package load in some image and that *doesn't* use any deprecated message! Deprecation methods aren't a solution. The package *must* be upgraded to the new API or a compatibility layer must be installed. Any of them are chores of the maintainer, and the user must not even know what had to be done in order for the package to work for him. -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Guillermo Polito

Oh, come on... Levente, we all agree with you. Pharo is trying to use that deprecation policy since some months ago... Sometimes people make mistakes (me included) and don't do it, but we agreed that we have to deprecate and remove after two versions of being deprecated. I'm tired of this stupid arguments. I expect the new year will bring us more doing and less discussing :). 2010/12/31 Levente Uzonyi <leves(a)elte.hu> > On Fri, 31 Dec 2010, Miguel CobÃ¡ wrote: > > El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribiÃ³: >> >>> What you describe here is simply bad practice. One should run the tests >>> before deploying code (besides testing the complete system thoroughly). >>> If you use RFB, you can access the GUI in headless mode. Also when a >>> debugger opens with a deprecation warning, the stack trace is written to >>> the log file, so you will be notified about the problem even when you >>> don't have access to the GUI. >>> >> >> Yeah, sure. But if it a second level dependency (a package I use that >> uses a package that contains popups deprecation warnings) I have big >> chances of being bite by this problem. I concede, this could be avoided >> by test-running every and whatnot package in the image but for a system >> that updates automatically this will bite. >> > > So you're saying that it's better to get a DNU instead of a deprecation > warning with proper description about what and how to update/change? > > > Levente > > > Also, even if I can use RFB or read the image logs, I most likely will >> monitor the application logs and will pass a time without me knowing >> that some part of the application is waiting some user input. >> At the end I expect that the maintainer of the package is the >> *responsible* of test the application for the image I use, and not the >> user of the package. That is what I do with magma on Pharo. I test and >> fix the issues generated by the evolution of Pharo and then I release a >> new ConfigurationOfMagma that the user can use without knowing that n >> deprecations were involved in the upgrade of the package. >> >> >> >>> Anyway, there's no reason to remove a method (especially an API method) >>> without deprecating and keeping it around for a few releases. >>> >>> >> I agree that is better to not forget to mark some method as deprecated >> but, again, I think that this promote the external packages not being >> updated to the current pharo image. >> >> Cheers >> >> -- >> Miguel CobÃ¡ >> http://twitter.com/MiguelCobaMtz >> http://miguel.leugim.com.mx >> >> >> >> >>

Dec. 31, 2010

Re: [Pharo-project] [squeak-dev] Fireworks 2011

by Francisco Ortiz PeÃ±aloza

Nice, thanks and happy new year for you all! Fran On Fri, Dec 31, 2010 at 3:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Thanks a lot alexander > It was really cool. > > Stupidly I increased the volume waiting for the final fireworks :) > > Stef > > > > On Dec 31, 2010, at 5:12 PM, Alexander LazareviÄ wrote: > > > Just found some old code of mine and pushed it to squeaksource. > > > > In a 4.1 Squeak or recent trunk image do > > > > (Installer repository: 'http://www.squeaksource.com/Fireworks') install: > 'Fireworks'. > > (Smalltalk at: #FireworksAnimation) start. > > > > In a 1.1.1 Pharo image do > > > > ((Gofer new squeaksource: 'Fireworks') package: 'Fireworks') load. > > (Smalltalk at: #FireworksAnimation) start. > > > > :D > > > > All the best for 2011, > > Alex > > > > PS: ALT-. or CMD-. will help ;) > > > > >

Dec. 31, 2010