Oh, remoteString!!! I LOVE IT :)))

Stephane, remember this mail ?
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 ([email protected]) 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
[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
[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

Reply via email to