On May 3, 2009, at 1:09 AM, Igor Stasenko wrote: > Oh, remoteString!!! I LOVE IT :))) > > Stephane, remember this mail ?
no :) but I agree we will have to address that in the future. But this will be a bit more complex > > I didn't sent it to list. Sending now, just as a reminder. > > 9 December 2008 05:20 > subject One big mess :) > > Here is an IRC log me chatting with Keith. > > I just hope that Pharo guys will address this issue somewhere in > future. > > [03:36] <sig__> btw, i just found your #7239 > [03:36] <sig__> i'm also took a look at this code time ago > [03:36] <sig__> and i would recommend following: > [03:37] <sig__> - completely remove using RemoteString from practice. > [03:37] <sig__> - make sure that access to source streams is > synchronized > [03:37] <sig__> (no concurrency issues) > [03:37] *** optikalmouse (n=u...@bas1- > toronto10-1279398477.dsl.bell.ca) joined > [03:38] <keithy> its a big job I started looking at it last wek > [03:38] <sig__> RemoteString is very , very , very brittle thing yes a terrible one :) > > [03:38] <keithy> do add you comment > [03:39] <sig__> i wouldn't pass anything except actual source code > outside source handling/management code > [03:39] <keithy> definitely > [03:39] <keithy> hmm > [03:39] *** wgsilkie ([email protected]) joined > [03:39] <keithy> or a proxy? > [03:39] <sig__> remote string is a proxy! > [03:40] <keithy> so... "I am a method" could I have my source please > [03:40] <sig__> but you can easily damage source files with it > [03:40] <sig__> or make it read complete mess instead of code > [03:42] <sig__> because , from what i have seen, it assumes that there > is nobody else accessing the source stream ATM, except single instance > of RemoteString > [03:46] <sig__> as well, as i don't like when different code in > different classes able to manipulate with the source streams directly > [03:46] <keithy> its ludicrous > [03:46] <sig__> by passing array with two elements around > [03:49] <sig__> check the references to SourceFiles :) > [03:50] <sig__> 55 references in my image! > [03:51] <sig__> a single, big, open wide security HOLE! :) > [03:52] <keithy> and lots of horrible code > [03:52] <sig__> yeah I totally agree. > > [03:52] *** wgsilkie quit (Remote closed the connection) > [03:53] <sig__> (SourceFiles at: 2) > [03:53] <sig__> very illustrative bit of code :) > [03:54] *** bmp > (n=benja...@207-237-69-172.c3-0.avec-ubr3.nyr-avec.ny.static.cable.rcn.com > ) > joined > [03:55] <sig__> things like that makes me smile, when Edgar says "my > image smaller , and therefore more modular" > [03:55] <sig__> for GOD SAKE!! > [03:59] <keithy> hmm, if you gzip the image does it get more modular? > [04:00] <sig__> it is clear, that source management subsystem deserves > a separate, well defined protocol. Without any exposure where it > reads/takes source from, or where storing to > [04:03] <sig__> and i can't call it a bug, it doesn't fits into any > imaginable bugs category, simply because its not a bug, but design > flaw > [04:04] <sig__> and i think it would require few weeks to make it > fixed > [04:04] <keithy> an implementation flaw, no design obvious > [04:04] *** lamneth2 ([email protected] > ) joined > [04:05] <sig__> well, an implementation should always follow a design > [04:05] <sig__> actually a bug, to my sense, is an implementation flaw > [04:06] <sig__> when it doesn't follows design > [04:06] <sig__> but design flaw is when everything works (no bugs), > but it works in an awfull way :) > > > > 2009/5/2 Stéphane Ducasse <[email protected]>: >> Apparnetly after 10296 I can load moose without problem. >> So the fixes of nicolas closing remoteString solved the problem. >> Now this is only partially solved since I would really like to >> understand >> why it broke in the first place since we did not touch this code. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
