September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Interesting Date/Time Thread on Squeak Dev

by Sean P. DeNigris

Max Leske wrote > your change It's not mine. I just scanned the thread from Squeak Dev and was intrigued because I've run into this limitation (the tension between year/month/etc as a conceptual ideal, and those entities as a specific number of days in context) a bunch before ----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 19, 2014

Re: [Pharo-dev] Interesting Date/Time Thread on Squeak Dev

by Sven Van Caekenberghe

Part of that is in https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken Furthermore, I am not so sure all this is a good idea, year/month durations are not constants and are dealt with differently in many context (say the financial world). January 30 + 1 month ? January 31 + 1 month ? Februari 29 2004 + 1 year ? And given all sorts of cleverness, will basic math rules still work ? A +B = B + A A + B = C => C - B = A On 19 Sep 2014, at 13:54, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > From > http://forum.world.st/Next-version-of-Date-DateAndTime-and-Duration-API-upd… > : > > Now in the InBox: > KernelTests-cbc.278.mcz > Kernel-cbc.871.mcz > The tests add in test for expected Duration addition and subtraction from > each other, including the new GenericMonth and GenericYear, and the very new > GenericDuration. It also adds a few more tests for LeapYear tests with > adding years to them. > > The test are still based on what it currently does, with the exceptions > listed previously (I haven't really changed any to expect failures, as has > been suggested - that will come shortly. For now, I want to try to cause > little to no changes o expected behavior first - just new behavior for now). > > Kernel adds the GenericDuration, and handles adding and subtracting > GenericMonth, GenericYear, and GenericDurations togeher in a rational way. > This involves turning + and - in Durations into a double-dispatch so that it > will work. > > There are no comments yet in these classes - they will be there before the > weekend is over at the latest. > > Any comments are more than welcome. > > -cbc > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 19, 2014

Re: [Pharo-dev] Implementing lazy loading for expandable collections

by Max Leske

On 19.09.2014, at 14:06, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2014-09-19 13:55 GMT+02:00 Markus Fritsche <mfritsche(a)reauktion.de>: > On 2014-09-19 11:35, Max Leske wrote: > > - my implementation requires an extra instance variable in > OrderedCollection to store the requested size. This extra instance > variable will break Monticello (and possibly other tools) because > Monticello uses OrderedCollections to load code and the particular way > it uses them makes it impossible to change the number of instance > variables on OrderedCollection. Also, all .mcz files written after the > change will not be loadable by images without the new instance > variable (same reason). > > I might be a bit fundamentalistic, but shouldn't this (a using class > making assumptions about the objects it's using) be considered a bug > by object oriented standards? > > Best regards > Markus > > > It's not the using class per se. > It's that MC is using a serialization framework sensitive to internal object representation (number/order of ivars). IIRC, MC counts the number of inst vars in the implementation that is being loaded and then assumes that the current implementation has the same number of fields. It might actually be quite easy to simply use the min of the number of instance variables and ignore the rest. However, that would not address the problem of modified variable position (which is a problem at least in theory). > The question is this one: > - would using FUEL would have resolved the problem or not? Partly. You could tell Fuel to migrate to the new layout dynamically which would allow reading of the old format as well as reading and writing of the new format. It wouldnât be exactly âniceâ though. > - wouldn't a serialization using message sends to reconstruct the objects be more robust (future proof)? > Of course the later requires the maintenance of a well defined API, so the robstness is relative. > But at least, it would respect the object paradigm a bit more. > > Nicolas

Sept. 19, 2014

Re: [Pharo-dev] Interesting Date/Time Thread on Squeak Dev

by Max Leske

Hi Sean, did you see issue 13229 (https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken)? It adds a new class AnnualDuration to allow for correct year based arithmetics. It also introduces floats for seconds (with nano seconds as base). I guess that issue and your change will conflict but as I understand it, your change probably does pretty much the same (for the year part at least)? Could you take a look? Cheers, Max On 19.09.2014, at 13:54, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > From > http://forum.world.st/Next-version-of-Date-DateAndTime-and-Duration-API-upd… > : > > Now in the InBox: > KernelTests-cbc.278.mcz > Kernel-cbc.871.mcz > The tests add in test for expected Duration addition and subtraction from > each other, including the new GenericMonth and GenericYear, and the very new > GenericDuration. It also adds a few more tests for LeapYear tests with > adding years to them. > > The test are still based on what it currently does, with the exceptions > listed previously (I haven't really changed any to expect failures, as has > been suggested - that will come shortly. For now, I want to try to cause > little to no changes o expected behavior first - just new behavior for now). > > Kernel adds the GenericDuration, and handles adding and subtracting > GenericMonth, GenericYear, and GenericDurations togeher in a rational way. > This involves turning + and - in Durations into a double-dispatch so that it > will work. > > There are no comments yet in these classes - they will be there before the > weekend is over at the latest. > > Any comments are more than welcome. > > -cbc > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 19, 2014

Re: [Pharo-dev] Implementing lazy loading for expandable collections

by Nicolas Cellier

2014-09-19 13:55 GMT+02:00 Markus Fritsche <mfritsche(a)reauktion.de>: > On 2014-09-19 11:35, Max Leske wrote: > > - my implementation requires an extra instance variable in >> OrderedCollection to store the requested size. This extra instance >> variable will break Monticello (and possibly other tools) because >> Monticello uses OrderedCollections to load code and the particular way >> it uses them makes it impossible to change the number of instance >> variables on OrderedCollection. Also, all .mcz files written after the >> change will not be loadable by images without the new instance >> variable (same reason). >> > > I might be a bit fundamentalistic, but shouldn't this (a using class > making assumptions about the objects it's using) be considered a bug > by object oriented standards? > > Best regards > Markus > > It's not the using class per se. It's that MC is using a serialization framework sensitive to internal object representation (number/order of ivars). The question is this one: - would using FUEL would have resolved the problem or not? - wouldn't a serialization using message sends to reconstruct the objects be more robust (future proof)? Of course the later requires the maintenance of a well defined API, so the robstness is relative. But at least, it would respect the object paradigm a bit more. Nicolas

Sept. 19, 2014

Re: [Pharo-dev] Versioner does not work on Pharo 4

by kilon alios

just for the record I have not created any kind of configuration in Ephestos. The code that you can download from Smalltalkhub or github is the only thing that lives inside the image. I use Smalltalkhub as a backup for github repo until I make sure filetree is a reliable way to work with github and pharo. I have not touche any of the internals of Pharo all my code lives inside the SThub repo. Other than the steps I described , and the code you can get from sthub I have done nothing to the pharo image. Also I forgot to say I dont mind at all late replies, I did not want to imply that I was annoyed or anything like that with people not replying. Its perfectly ok to not reply to my threads or reply days afterwards or even moths. I have in my hand scientific evidence that I am not the center of this world. Thank you Christopher and everyone who is trying to help me in each of my problems. I really appreciate it. On Fri, Sep 19, 2014 at 12:49 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > I dont use a startup script myself, in windows the image with problem is > release 40230, i download that specific release and it works o_O , so maybe > it was something I did afterall ? very strange > > so I attached my image folder, hope it helps you > > On Fri, Sep 19, 2014 at 12:39 PM, Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > >> >> Le 19 sept. 2014 Ã 11:21, kilon alios a Ã©crit : >> >> > Well to kepp you updated , because I did not bother replying to my own >> thread since none seemed to care or have the same issue as me. >> >> I was out of office last days ... >> >> > I tried on windows again same error as macos on a fresh image by the >> way. So I know it must not be me. >> >> On which image? I just tried on a fresh 3.0 image and it also works for >> me. >> >> > The only things I am doing with pharo is >> > >> > 1) use dark theme >> > >> > 2) use free type font Arial on windows and Monaco on macos >> > >> > 3) use filetree for working with a git directory. >> >> Maybe a side effect. >> Could you give me a script to help reproducing the problem? Maybe just >> your startup script. >> Does the problem appear the first time you open Versionner? >> >> Thanks, >> Christophe. > > >

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Sven Van Caekenberghe

On 19 Sep 2014, at 13:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tudor Girba-2 wrote >> package: 'ConfigurationOfOpenDBXDriver'; >> load. >> #ConfigurationOfOpenDBXDriver asClass loadBleedingEdge. > > configurationOf: 'OpenDBXDriver'; > loadVersion: #bleedingEdge. > > :) Yes please. Check out #configuration, #loadStable, #loadDevelopment as well - only group loading is not there.

Sept. 19, 2014

Re: [Pharo-dev] Implementing lazy loading for expandable collections

by Markus Fritsche

On 2014-09-19 11:35, Max Leske wrote: > - my implementation requires an extra instance variable in > OrderedCollection to store the requested size. This extra instance > variable will break Monticello (and possibly other tools) because > Monticello uses OrderedCollections to load code and the particular way > it uses them makes it impossible to change the number of instance > variables on OrderedCollection. Also, all .mcz files written after the > change will not be loadable by images without the new instance > variable (same reason). I might be a bit fundamentalistic, but shouldn't this (a using class making assumptions about the objects it's using) be considered a bug by object oriented standards? Best regards Markus

Sept. 19, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40235 Home: https://github.com/pharo-project/pharo-core

Sept. 19, 2014

[pharo-project/pharo-core] 31716f: 40235

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 31716ff672da83deb83bf7f262f0890fd0e105be https://github.com/pharo-project/pharo-core/commit/31716ff672da83deb83bf7f2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-19 (Fri, 19 Sep 2014) Changed paths: R KernelTests.package/JobTest.class/instance/tests/testCurrent.st A Ring-Core-Kernel.package/RGClassDefinition.class/class/instance creation/createSharedPoolNamed_.st M Ring-Core-Kernel.package/RGClassDefinition.class/instance/shared pools/addSharedPoolNamed_.st R Ring-Core-Kernel.package/RGFactory.class/instance/factory/createClassVariableNamed_parent_.st R Ring-Core-Kernel.package/RGFactory.class/instance/factory/createPoolVariableNamed_parent_.st R Ring-Core-Kernel.package/RGFactory.class/instance/factory/createSharedPoolNamed_.st M Ring-Tests-Kernel.package/RGGlobalDefinitionTest.class/instance/testing/testPoolDefinition.st M Ring-Tests-Kernel.package/RGVariableDefinitionTest.class/instance/testing/testClassVariable.st M Ring-Tests-Kernel.package/RGVariableDefinitionTest.class/instance/testing/testPoolVariable.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script235.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40235.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/messageList interface/open.st Log Message: ----------- 40235 14038 #testSendersOfAt failing when running the tests in the image https://pharo.fogbugz.com/f/cases/14038 14039 #testCurrent always fails when running all tests... https://pharo.fogbugz.com/f/cases/14039 14041 Continue cleaning Ring Factory https://pharo.fogbugz.com/f/cases/14041 http://files.pharo.org/image/40/40235.zip

Sept. 19, 2014