- Pharo-dev - lists.pharo.org

Re: [Pharo-project] RE : cannot modify class comments on Linux

by Igor Stasenko

On 30 April 2013 11:24, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>wrote: > I think this was written with write once, read many restriction... > However, > - If the write stream would just append and not mess with position: > - And if the whole chunk was written in a single primitive call, > Then the write could still be safe, because primitive are currently > un-interruptible. > Otherwise, as for every shared ressource, proper locking should be used... > > But let's not do it: > Indeed, if the changes is no more a code repository, but just becomes a > failsafe change log, then we don't need anymore to log the content of code > we import (with MC or fileIn or other means...). > Logging the root action should be enough (MCLoaderOrSomething loadFromURL: > '....'!). > Thus, there would be no need for background logging, only the UI process > would log things and thus the write once model would be simple enough. > So, IMO, it's not usefull to waste cycles on something complex here. > Thoughts? > > Just to say i have same thoughts: system should log only user's direct actions which causing changes, not every single change. > Nicolas > > > 2013/4/30 GOUBIER Thierry <thierry.goubier(a)cea.fr> > >> I confirm, it's 1) >> >> Adding a flush just before reopening the file R-O for the RemoteString >> instance solves this problem. However, this isn't obvious (i.e. the R-O >> opening is lazily triggered by another RemoteString method). >> >> I don't like, from a threading point of view, the RemoteString writing >> code. It takes the stream position before writing stuff in it, opening an >> opportunity window for a race condition. >> >> Thierry >> >> ________________________________________ >> De : pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Henrik >> Johansen [henrik.s.johansen(a)veloxit.no] >> Date d'envoi : lundi 29 avril 2013 11:54 >> Ã : Pharo-project(a)lists.gforge.inria.fr >> Objet : Re: [Pharo-project] cannot modify class comments on Linux >> >> On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote: >> >> > To be perfectly clear, does the bug occurs >> > 1) because we open a new file descriptor for read without flushing the >> old one for write, >> > 2) or does it occur with a single file descriptor opened 'rw' ? >> > >> > If 1), then this is probably our fault. >> > If 2), then I wouldn't expect such behavior. >> >> 1), different streams are used for reading/writing, to reduce threading >> errors in relation to position usage. >> RemoteStrings have an unusual tendency to jump around a lot in the >> streams they're linked to, which is no fun if you, say, try and write new >> source at the same time in a different thread. >> >> Cheers, >> Henry >> >> > -- Best regards, Igor Stasenko.

April 30, 2013

Re: [Pharo-project] RE : cannot modify class comments on Linux

by Nicolas Cellier

I think this was written with write once, read many restriction... However, - If the write stream would just append and not mess with position: - And if the whole chunk was written in a single primitive call, Then the write could still be safe, because primitive are currently un-interruptible. Otherwise, as for every shared ressource, proper locking should be used... But let's not do it: Indeed, if the changes is no more a code repository, but just becomes a failsafe change log, then we don't need anymore to log the content of code we import (with MC or fileIn or other means...). Logging the root action should be enough (MCLoaderOrSomething loadFromURL: '....'!). Thus, there would be no need for background logging, only the UI process would log things and thus the write once model would be simple enough. So, IMO, it's not usefull to waste cycles on something complex here. Thoughts? Nicolas 2013/4/30 GOUBIER Thierry <thierry.goubier(a)cea.fr> > I confirm, it's 1) > > Adding a flush just before reopening the file R-O for the RemoteString > instance solves this problem. However, this isn't obvious (i.e. the R-O > opening is lazily triggered by another RemoteString method). > > I don't like, from a threading point of view, the RemoteString writing > code. It takes the stream position before writing stuff in it, opening an > opportunity window for a race condition. > > Thierry > > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Henrik > Johansen [henrik.s.johansen(a)veloxit.no] > Date d'envoi : lundi 29 avril 2013 11:54 > Ã : Pharo-project(a)lists.gforge.inria.fr > Objet : Re: [Pharo-project] cannot modify class comments on Linux > > On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote: > > > To be perfectly clear, does the bug occurs > > 1) because we open a new file descriptor for read without flushing the > old one for write, > > 2) or does it occur with a single file descriptor opened 'rw' ? > > > > If 1), then this is probably our fault. > > If 2), then I wouldn't expect such behavior. > > 1), different streams are used for reading/writing, to reduce threading > errors in relation to position usage. > RemoteStrings have an unusual tendency to jump around a lot in the streams > they're linked to, which is no fun if you, say, try and write new source at > the same time in a different thread. > > Cheers, > Henry > >

April 30, 2013

[Pharo-project] RE : cannot modify class comments on Linux

by GOUBIER Thierry

I confirm, it's 1) Adding a flush just before reopening the file R-O for the RemoteString instance solves this problem. However, this isn't obvious (i.e. the R-O opening is lazily triggered by another RemoteString method). I don't like, from a threading point of view, the RemoteString writing code. It takes the stream position before writing stuff in it, opening an opportunity window for a race condition. Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Henrik Johansen [henrik.s.johansen(a)veloxit.no] Date d'envoi : lundi 29 avril 2013 11:54 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote: > To be perfectly clear, does the bug occurs > 1) because we open a new file descriptor for read without flushing the old one for write, > 2) or does it occur with a single file descriptor opened 'rw' ? > > If 1), then this is probably our fault. > If 2), then I wouldn't expect such behavior. 1), different streams are used for reading/writing, to reduce threading errors in relation to position usage. RemoteStrings have an unusual tendency to jump around a lot in the streams they're linked to, which is no fun if you, say, try and write new source at the same time in a different thread. Cheers, Henry

April 30, 2013

[Pharo-project] [update 3.0] #30076

by Marcus Denker

30076 ----- 10453 cleanup logMethodSource2:... and compile2: https://pharo.fogbugz.com/f/cases/10453 10451 Compiler API: compatibility API class side --> instance side https://pharo.fogbugz.com/f/cases/10451 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Traits-MarcusDenker.485 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Monticello-MarcusDenker.792 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/KernelTests-MarcusDenker.493 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1396 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Compiler-MarcusDenker.418

April 30, 2013

Re: [Pharo-project] [regression reporter]regression occurred

by Sven Van Caekenberghe

On 30 Apr 2013, at 10:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 30, 2013, at 10:30 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 30 Apr 2013, at 08:53, no-reply(a)ci.inria.fr wrote: >> >>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… >>> >>> 1 regressions found. >>> Zinc.Tests.ZnClientTests.testPostMultipart >> >> This seems like a compiler problem to me: how else could (client := ZnClient new) return a SmallInteger ? >> > > This is a vm bug, I think. Nice ;-) >> Error Message >> >> SmallInteger>>url: >> >> Stacktrace >> >> SmallInteger(Object)>>doesNotUnderstand: #url: >> [:server | >> (client := ZnClient new) url: server localUrl; >> addPath: 'echo'; >> >> addPart: (ZnMimePart fieldName: 'username' value: 'john'); >> >> addPart: (ZnMimePart >> fieldName: 'foo' >> entity: (ZnEntity text: '123')); >> >> addPart: (ZnMimePart fieldName: 'file' fileNamed: filename); >> post. >> self assert: client isSuccess. >> self >> assert: (client contents includesSubstring: 'multipart')] in ZnClientTests>>testPostMultipart >> BlockClosure>>cull: >> [server start. >> self assert: server isRunning & server isListening. >> block cull: server] in ZnClientTests>>withServerDo: >> BlockClosure>>ensure: >> ZnClientTests>>withServerDo: >> ZnClientTests>>testPostMultipart >> ZnClientTests(TestCase)>>performTest >> >> > >

April 30, 2013

Re: [Pharo-project] [regression reporter]regression occurred

by Marcus Denker

On Apr 30, 2013, at 10:30 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Apr 2013, at 08:53, no-reply(a)ci.inria.fr wrote: > >> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… >> >> 1 regressions found. >> Zinc.Tests.ZnClientTests.testPostMultipart > > This seems like a compiler problem to me: how else could (client := ZnClient new) return a SmallInteger ? > This is a vm bug, I think. > Error Message > > SmallInteger>>url: > > Stacktrace > > SmallInteger(Object)>>doesNotUnderstand: #url: > [:server | > (client := ZnClient new) url: server localUrl; > addPath: 'echo'; > > addPart: (ZnMimePart fieldName: 'username' value: 'john'); > > addPart: (ZnMimePart > fieldName: 'foo' > entity: (ZnEntity text: '123')); > > addPart: (ZnMimePart fieldName: 'file' fileNamed: filename); > post. > self assert: client isSuccess. > self > assert: (client contents includesSubstring: 'multipart')] in ZnClientTests>>testPostMultipart > BlockClosure>>cull: > [server start. > self assert: server isRunning & server isListening. > block cull: server] in ZnClientTests>>withServerDo: > BlockClosure>>ensure: > ZnClientTests>>withServerDo: > ZnClientTests>>testPostMultipart > ZnClientTests(TestCase)>>performTest > >

April 30, 2013

Re: [Pharo-project] [regression reporter]regression occurred

by Sven Van Caekenberghe

On 30 Apr 2013, at 08:53, no-reply(a)ci.inria.fr wrote: > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… > > 1 regressions found. > Zinc.Tests.ZnClientTests.testPostMultipart This seems like a compiler problem to me: how else could (client := ZnClient new) return a SmallInteger ? Error Message SmallInteger>>url: Stacktrace SmallInteger(Object)>>doesNotUnderstand: #url: [:server | (client := ZnClient new) url: server localUrl; addPath: 'echo'; addPart: (ZnMimePart fieldName: 'username' value: 'john'); addPart: (ZnMimePart fieldName: 'foo' entity: (ZnEntity text: '123')); addPart: (ZnMimePart fieldName: 'file' fileNamed: filename); post. self assert: client isSuccess. self assert: (client contents includesSubstring: 'multipart')] in ZnClientTests>>testPostMultipart BlockClosure>>cull: [server start. self assert: server isRunning & server isListening. block cull: server] in ZnClientTests>>withServerDo: BlockClosure>>ensure: ZnClientTests>>withServerDo: ZnClientTests>>testPostMultipart ZnClientTests(TestCase)>>performTest

April 30, 2013

Re: [Pharo-project] SmallintRule on the whole system

by Camille Teruel

On 30 avr. 2013, at 09:50, Camillo Bruni wrote: >>> http://stackoverflow.com/questions/16294844/run-smalllint-rule-on-all-class… Yes #run is useless (I open a bug entry so it run on all the system by default). Use #runOnEnvironment: instead: RBUnclassifiedMethodsRule new runOnEnvironment: RBBrowserEnvironment new; result

April 30, 2013

[Pharo-project] SmallintRule on the whole system

by Camillo Bruni

>> http://stackoverflow.com/questions/16294844/run-smalllint-rule-on-all-class…

April 30, 2013

[Pharo-project] Synchronous Spec

by roberto.minelli＠usi.ch

Hi, As far as I understood, Spec is sort of asynchronous, let me explain. I implemented my ComposableModel (i.e., MyWindow) as a window with a TextModel, a DropList model, and two buttons: ok and cancel. The behavior I want to achieve is something that is easily doable with StandardWindow, something like name := StandardWindow new textEntry: 'Please enter a name'. Until the window stays open, the call does not return and once ok is pressed the result is stored in the 'name' variable. Now with Spec I've something like 'MyWindow new openWithSpec', but the call returns immediately. What is the best way to achieve such behavior? Thanks in advance. Cheers, Roberto

April 30, 2013