- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Clock/Delay problems

by Igor Stasenko

My personal take about this issue: - when image starting up, all Delays should be reset by unblocking all waiting processes (regardless how much extra time there left to be waiting). Because, to my opinion, a code which uses delays to cross session boundaries will fail badly anyways, so imo it is better to have delays unblocked the process prematurely, rather than blocking it for next 2^30 milliseconds (or any random big number around that). -- Best regards, Igor Stasenko.

Feb. 13, 2013

Re: [Pharo-project] Clock/Delay problems

by Igor Stasenko

On 13 February 2013 18:01, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Sven > > can you add a bug entry because igor and camillo were discussing about the > strange logic of DateAndTime? > yeah.. i was looking at it recently (remember my post about DateAndTime nanosecond precision handling).. still did not found anything which causing the problems. there is too much stuff involved during startup... and since you cannot debug that code, you cannot see what happens :( > Stef > > On Feb 11, 2013, at 2:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I have seen this before, and it is probably related to other problems that > we have been seeing lately: > > <PharoScreenshot.png> > > Basically the whole initialization of DateAndTime (class side) goes wrong. > > Could this have something to do with Delay problems ? > > Some time ago, there were some Delay changes, right ? > > I have not yet made an issue, as I think we should discuss a bit first. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > -- Best regards, Igor Stasenko.

Feb. 13, 2013

Re: [Pharo-project] Enums with negative values don't work properly.

by Igor Stasenko

Good news: - i reverted the image-side code back in 2.1 version i don't like adding new primitives, and since i found the way to access required symbols on windows VM by exporting them, this will allow the old versions of NB to run without changes on newer VMs. In new VMs, there are also changes to primitive 220 (primitiveVoltage ;). It is mostly dormant NB feature right now, but it is important to have it working correctly for the future. Today we were doing last steps with Esteban, integrating all changes & fixing minor details.. now we are at stage of making things work on jenkins (can take couple more days, because we have to reinstall mac slave). -- Best regards, Igor Stasenko.

Feb. 13, 2013

Re: [Pharo-project] OSProcess and CommandShell in Pharo 2.0

by phil＠highoctane.be

Got the configuration to load in the latest 2.0. But when doing and edit test and doing a save, there is an error occuring. See screenshot. Hey, CommandShell is ubercool! Phil 2013/2/13 Sean P. DeNigris <sean(a)clipperadams.com>: > I think we have it now: > - ConfigurationOfOSProcess and ConfigurationOfCommandShell have been updated > to work in 1.4 and 2.0 > - Each config has been copied to its project repo (e.g. sqs/CommandShell). I > was starting to get confused with all the locations > (sqs/MetacelloRepository, xyz/MetaRepoForAbc, etc). I think it's a more sane > model to keep the configs with the project and then mirror them as > necessary. Metacello was designed to manage dialect dependencies, so there > should be no need to fork a ConfigurationOfXyz. The only issue we have is > when we don't have access to the project's repo, for which it'd be great if > we implement per-project inboxes ( maybe in StHub, hint, hint ;) ) > > Anyway, thanks to David and Steph for all the hard work getting this > working. OSP and CommandShell are vitally important projects and it's great > to know that they will continue working well in Pharo for the foreseeable > future :) > > > > -- > View this message in context: http://forum.world.st/OSProcess-and-CommandShell-in-Pharo-2-0-tp4669674.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 13, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by stephane ducasse

On Feb 13, 2013, at 4:06 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > stephane ducasse wrote >> @sean what was the problem because I tested it several time on 1.4 and 2.0 > > The tests were failing due to FS differences between 1.4 and 2.0. I uploaded > fixes, so we could do a 4.5.1 with the latest packages (4.5 is tagged > release so we shouldn't change it). Also, I moved the dependency on the > CommandShell version from the baseline (where I originally put it in error), > to the versions. Nobody use this 4.5 so we could just modify it. Because 4.5.1 looks boring to me. > For CommandShell, I moved CommandShellPharo into a #'pharo' block, and MVC > into a #'squeak' one. > > > > -- > View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669672.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 13, 2013

Re: [Pharo-project] Clock/Delay problems

by stephane ducasse

Sven can you add a bug entry because igor and camillo were discussing about the strange logic of DateAndTime? Stef On Feb 11, 2013, at 2:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I have seen this before, and it is probably related to other problems that we have been seeing lately: > > <PharoScreenshot.png> > > Basically the whole initialization of DateAndTime (class side) goes wrong. > > Could this have something to do with Delay problems ? > > Some time ago, there were some Delay changes, right ? > > I have not yet made an issue, as I think we should discuss a bit first. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill >

Feb. 13, 2013

[Pharo-project] OSProcess and CommandShell in Pharo 2.0

by Sean P. DeNigris

I think we have it now: - ConfigurationOfOSProcess and ConfigurationOfCommandShell have been updated to work in 1.4 and 2.0 - Each config has been copied to its project repo (e.g. sqs/CommandShell). I was starting to get confused with all the locations (sqs/MetacelloRepository, xyz/MetaRepoForAbc, etc). I think it's a more sane model to keep the configs with the project and then mirror them as necessary. Metacello was designed to manage dialect dependencies, so there should be no need to fork a ConfigurationOfXyz. The only issue we have is when we don't have access to the project's repo, for which it'd be great if we implement per-project inboxes ( maybe in StHub, hint, hint ;) ) Anyway, thanks to David and Steph for all the hard work getting this working. OSP and CommandShell are vitally important projects and it's great to know that they will continue working well in Pharo for the foreseeable future :) -- View this message in context: http://forum.world.st/OSProcess-and-CommandShell-in-Pharo-2-0-tp4669674.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 13, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by Sean P. DeNigris

stephane ducasse wrote > @sean what was the problem because I tested it several time on 1.4 and 2.0 The tests were failing due to FS differences between 1.4 and 2.0. I uploaded fixes, so we could do a 4.5.1 with the latest packages (4.5 is tagged release so we shouldn't change it). Also, I moved the dependency on the CommandShell version from the baseline (where I originally put it in error), to the versions. For CommandShell, I moved CommandShellPharo into a #'pharo' block, and MVC into a #'squeak' one. -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669672.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 13, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by Sean P. DeNigris

David T. Lewis wrote > I thought that I got rid of all the explicit references to FileDirectory > and > ReferenceStream, so check to make sure you're using the latest version of > OSProcess. Maybe I missed a few of the references, there were quite a few. I think you're right... don't know what I was looking at :/ The test errors I saw in 1.4 were due to FS differences between 1.4 and 2.0: - In 1.4 #ensureDeleted must be #delete - The only way to get the file delimiter that works in both 1.4 and 2.0 is "(Smalltalk at: #DiskStore) current perform: #delimiter" i.e. the send to #current was added I made the changes and uploaded to OSP and CommandShell sqs repos. It's nice to avoid Platform packages, and the conditionals are currently quarantined on the class-side of OSProcess, but Metacello would remove them from the codebase completely, just leaving a clean message send, where three branches had been... just sayin ;) - Sean -- View this message in context: http://forum.world.st/The-monkey-is-back-in-town-tp4658091p4669670.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 13, 2013

Re: [Pharo-project] Clock/Delay problems

by Camillo Bruni

Yes that is a very nasty bug, and I think it is not that easy to fix. If you really want to fix it we will have to fiddle with the whole startup mess. see comments in: https://code.google.com/p/pharo/issues/detail?id=7129 strangely enough it was introduced in 20460! image 20459 worked without problems. looking at the diffs doesn't reveal anything that could immediately cause the bug: 20459: https://github.com/pharo-project/pharo-core/commit/b83bda681530692a08efa430… 20460: https://github.com/pharo-project/pharo-core/commit/16fe676a4ff25d720340ac8c… 20461: https://github.com/pharo-project/pharo-core/commit/382d4c637b5f433edcb4d99d… 20462: https://github.com/pharo-project/pharo-core/commit/2aece46a9ac922a81e931309… the most probable change happened in 20462, but I am not sure if that is the cause. On 2013-02-11, at 14:54, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I have seen this before, and it is probably related to other problems that we have been seeing lately: > > > Basically the whole initialization of DateAndTime (class side) goes wrong. > > Could this have something to do with Delay problems ? > > Some time ago, there were some Delay changes, right ? yeah, in the case the image hangs, there are always a couple (5 - 10) processes hanging in the image due to the DateAndTime offset initialization stuff. So my guess is that by making that lazily initialized we could get rid of the bug. maybe you can dig into that direction, I don't have much time at hand these days ;)

Feb. 13, 2013