- Pharo-dev - lists.pharo.org

Re: [Pharo-project] interpreter cannot read image file

by Eliot Miranda

On Tue, Mar 27, 2012 at 12:36 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Hi, > > I'm trying to open an old production image based on Squeak 3.9.1 file > with CogVM and I get: > This interpreter (vers. 6505) cannot read image file (vers. 6502) > > I've always seen only the inverse report. Any idea how to convert the > image? > You can start from the closure bootstrap on my web site<http://www.mirandabanda.org/files/Cog/Closures0808/Bootstrap/>. But it's a lot of work, and even then there are lots of additional upgrades to get to a bug-free system. IMO it would be far better to try and recreate it. > > Cheers, > -- Pavel > > -- best, Eliot

March 28, 2012

Re: [Pharo-project] FileURL don't works properly on windows

by Gary Chambers

Then again... if you want cleverness you do a link on archaic filesystems that can't do a proper root... Personally I'd like a URI/URL to work crossly on multiple platforms in a reasonable manner. Otherwise it is a pain to work with Linux/Windows transparently. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, March 27, 2012 6:55 PM Subject: Re: [Pharo-project] FileURL don't works properly on windows > On 27 March 2012 19:50, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >> Give filesystem disparities I'd personally be happy with >> >> file://Pharo/xyz.abc >> >> resolving to >> >> C:\Pharo\xyz.abc >> >> on Windows... > > unless you meant > > D:\Pharo\xyz.abc > > :) > No. I don't like such implicit cleverness. Things should be stupid. No > magic. If it works it should work. If it doesn't , it should explain > why. > And let users solve the issue. > But when system tries to play a wizard which can read people's mind, > this is road to nowhere. > >> >> Regards, Gary >> >> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, March 27, 2012 6:41 PM >> >> Subject: Re: [Pharo-project] FileURL don't works properly on windows >> >> >> On 27 March 2012 18:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> >>> On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote: >>> >>>> this part is closely related to command-line arguments handling.. >>>> >>>> on windows things, which expected to work, like: >>>> >>>> vm image.image <pathToScript>.st >>>> >>>> fails to find the script, because it messing up with back/forward >>>> slashes in path >>>> and at the end it transforms an input into escaped slashes, which is >>>> of course cannot be found in file system... >>> >>> >>> >>> right now we use Urls there because it supports to add URL as a "file". >>> >>> vm imageimage http://myscript.com/phato.st >>> >>> I personally think we should remove that. If you want to load a file via >>> the network, just >>> write a local script that does that. >>> >>> If we remove the network support for script parameters, we will directly >>> solve that problem. >>> (and we simplify the whole startup logic, and we make the startup not >>> depend on networking). >>> >>> http://code.google.com/p/pharo/issues/detail?id=4057 >>> >>> Marcus >>> >> agree.. this thing is a bit overengineeeeered. >> but in overall it is cool to have, unless it breaks a most basic usage >> : hey ... a stupid file name passed as an argument! >> >> we can remove it, of course, but it won't make a FileURL a bit less >> broken.. >> since things like that: >> >> 'c:\myfile.txt' asURL retrieveContents still won't work. >> we should cover it by tests btw, since now we have windows.. >> but in order to run any test(s) we should fix this thing first :) >> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > > -- > Best regards, > Igor Stasenko. >

March 28, 2012

Re: [Pharo-project] Announcement vs SystemChangeNotifier

by Igor Stasenko

On 26 March 2012 12:45, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 26.03.2012 00:08, Igor Stasenko wrote: >> >> On 25 March 2012 21:49, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >> Â wrote: >>> >>> Hi guys >>> >>> I'm starting to look at how we can remove SystemChangeNotifier to only >>> use SystemAnnouncement. >>> Now >>> Â Â Â Â Is there an equivalent to >>> Â Â Â Â Â Â Â Â SystemChangeNotifier uniqueInstance doSilently: [â¦â¦] >>> >>> Â Â Â Â for Announcement? >>> > Not implemented (yet?). > > >> well, you can implement disabling announcer for a while.. >> >> announcer disableWhile: [... >> >> ... any announces here wont be delivered ..]. >> >> easy > > Following the original posts, the API should be suspendWhile: > http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&… > > And the reason I haven't done more than think about it, is respecting Igor's > security concerns about subscription modifications by external users really > complicates doing things like this in a good way... > The above announcer disableWhile: certainly break them in the most blatant > way possible :P > +100 yes.. now since i remember our discussion about it.. yes.. i am still against it. because it just violating the principle of least authority: - any guy who thinks he is a position to suspend announcements can do it, but since he doesn't knows who else subscribed to them, he simply can ruin the logic of other event consumers... I think we should think about other approach: In case of system changes notifier , a "do silently" was do not log the changes. That means that if we could have a logger plugged into system announcer, one should tell a system logger to ignore system notifications and do not log them for a while, instead of making system notifier suspending all subscriptions, leading to unknown consequences for the rest of event listeners! If guy wants to suspend logging, he should tell logger to suspend it.. like that, no other facilities will be affected. -- Best regards, Igor Stasenko.

March 28, 2012

Re: [Pharo-project] FileURL don't works properly on windows

by Sven Van Caekenberghe

On 27 Mar 2012, at 18:07, Igor Stasenko wrote: > The problem is in FileUrl, > which is related to different path encoding scheme on windows (use > drive letter(s), and back slashes instead of normal ones).. > i'm not sure if Zinc can help there, because its urls mostly for > http.. if i'm not mistaken. Yes, ZnUrl is HTTP(S) specific and does not include a number of aspect that are in URL like uername and password. File URLs (http://en.wikipedia.org/wiki/File_URI_scheme) are more complicated because of platform differences, the way things seem to be on Windows is a bit scary, for me at least. Cleaning up and/or unifying the URL/URI mess would be a nice project. >> No so simple I know but... >> >> Le 27 mars 2012 17:18, "Marcus Denker" <marcus.denker(a)inria.fr> a Ã©crit : >> >>> >>> On Mar 27, 2012, at 4:05 PM, Igor Stasenko wrote: >>> >>>> Try: >>>> >>>> (FileDirectory default / 'foo') asUrl retrieveContents >>> >>> >>> Yes, we need to really do a pass over the Url... there is Url (from old >>> Squeak). >>> The there is URI, a package from Impara that we wanted to replace Url in >>> Squeak 3.9 >>> but development stopped when Impara could not contribute to Squeak anymore >>> (due to politics...). >>> >>> Then there is ZnUrl... >>> >>> Definitly needs cleanup. We need one model for Url that works. >>> >>> Marcus >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >> > > >

March 28, 2012

Re: [Pharo-project] FileURL don't works properly on windows

by Igor Stasenko

On 27 March 2012 19:50, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > Give filesystem disparities I'd personally be happy with > > file://Pharo/xyz.abc > > resolving to > > C:\Pharo\xyz.abc > > on Windows... unless you meant D:\Pharo\xyz.abc :) No. I don't like such implicit cleverness. Things should be stupid. No magic. If it works it should work. If it doesn't , it should explain why. And let users solve the issue. But when system tries to play a wizard which can read people's mind, this is road to nowhere. > > Regards, Gary > > ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, March 27, 2012 6:41 PM > > Subject: Re: [Pharo-project] FileURL don't works properly on windows > > > On 27 March 2012 18:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote: >> >>> this part is closely related to command-line arguments handling.. >>> >>> on windows things, which expected to work, like: >>> >>> vm image.image <pathToScript>.st >>> >>> fails to find the script, because it messing up with back/forward >>> slashes in path >>> and at the end it transforms an input into escaped slashes, which is >>> of course cannot be found in file system... >> >> >> >> right now we use Urls there because it supports to add URL as a "file". >> >> vm imageimage http://myscript.com/phato.st >> >> I personally think we should remove that. If you want to load a file via >> the network, just >> write a local script that does that. >> >> If we remove the network support for script parameters, we will directly >> solve that problem. >> (and we simplify the whole startup logic, and we make the startup not >> depend on networking). >> >> http://code.google.com/p/pharo/issues/detail?id=4057 >> >> Marcus >> > agree.. this thing is a bit overengineeeeered. > but in overall it is cool to have, unless it breaks a most basic usage > : hey ... a stupid file name passed as an argument! > > we can remove it, of course, but it won't make a FileURL a bit less broken.. > since things like that: > > 'c:\myfile.txt' asURL retrieveContents still won't work. > we should cover it by tests btw, since now we have windows.. > but in order to run any test(s) we should fix this thing first :) > >> >> -- >> Marcus Denker -- http://marcusdenker.de >> > > > > -- > Best regards, > Igor Stasenko. > > -- Best regards, Igor Stasenko.

March 28, 2012

Re: [Pharo-project] vm crash - code snippet provided

by Igor Stasenko

On 26 March 2012 01:54, Francisco Garau <francisco.garau(a)gmail.com> wrote: > It's used to "animate" the morphs, apparently. > > The crash happens quite easily by dragging a big window out of the screen > (to the left). You either get a debugger or the vm crashes. > > I just want to point out that before the VM crashes, there is a bug in > Smalltalk-land; an Number is appearing where a Point is expected. > Yeah.. i am aware of that. It looks like i should spend some time and fix my precious demo to check bounds before blindly copying bits from opengl buffer to Display. I described the problem in previous discussion, and i know what exactly should be done... but i haven't time to address that.. i have more important things to do. Just want to repeat again: That demo was just for the DEMO purposes.. it was not designed for general purpose.. It would be nice if someone could spend time improving it and getting rid of obvious mistakes, like missed range checking. But till then, take it with grain and salt. > - Francisco -- Best regards, Igor Stasenko.

March 28, 2012

Re: [Pharo-project] FileURL don't works properly on windows

by Gary Chambers

Maybe an extra / there... else relative etc. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, March 27, 2012 6:41 PM Subject: Re: [Pharo-project] FileURL don't works properly on windows On 27 March 2012 18:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote: > >> this part is closely related to command-line arguments handling.. >> >> on windows things, which expected to work, like: >> >> vm image.image <pathToScript>.st >> >> fails to find the script, because it messing up with back/forward >> slashes in path >> and at the end it transforms an input into escaped slashes, which is >> of course cannot be found in file system... > > > right now we use Urls there because it supports to add URL as a "file". > > vm imageimage http://myscript.com/phato.st > > I personally think we should remove that. If you want to load a file via > the network, just > write a local script that does that. > > If we remove the network support for script parameters, we will directly > solve that problem. > (and we simplify the whole startup logic, and we make the startup not > depend on networking). > > http://code.google.com/p/pharo/issues/detail?id=4057 > > Marcus > agree.. this thing is a bit overengineeeeered. but in overall it is cool to have, unless it breaks a most basic usage : hey ... a stupid file name passed as an argument! we can remove it, of course, but it won't make a FileURL a bit less broken.. since things like that: 'c:\myfile.txt' asURL retrieveContents still won't work. we should cover it by tests btw, since now we have windows.. but in order to run any test(s) we should fix this thing first :) > > -- > Marcus Denker -- http://marcusdenker.de > -- Best regards, Igor Stasenko.

March 28, 2012

Re: [Pharo-project] FileURL don't works properly on windows

by Gary Chambers

Give filesystem disparities I'd personally be happy with file://Pharo/xyz.abc resolving to C:\Pharo\xyz.abc on Windows... Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, March 27, 2012 6:41 PM Subject: Re: [Pharo-project] FileURL don't works properly on windows On 27 March 2012 18:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote: > >> this part is closely related to command-line arguments handling.. >> >> on windows things, which expected to work, like: >> >> vm image.image <pathToScript>.st >> >> fails to find the script, because it messing up with back/forward >> slashes in path >> and at the end it transforms an input into escaped slashes, which is >> of course cannot be found in file system... > > > right now we use Urls there because it supports to add URL as a "file". > > vm imageimage http://myscript.com/phato.st > > I personally think we should remove that. If you want to load a file via > the network, just > write a local script that does that. > > If we remove the network support for script parameters, we will directly > solve that problem. > (and we simplify the whole startup logic, and we make the startup not > depend on networking). > > http://code.google.com/p/pharo/issues/detail?id=4057 > > Marcus > agree.. this thing is a bit overengineeeeered. but in overall it is cool to have, unless it breaks a most basic usage : hey ... a stupid file name passed as an argument! we can remove it, of course, but it won't make a FileURL a bit less broken.. since things like that: 'c:\myfile.txt' asURL retrieveContents still won't work. we should cover it by tests btw, since now we have windows.. but in order to run any test(s) we should fix this thing first :) > > -- > Marcus Denker -- http://marcusdenker.de > -- Best regards, Igor Stasenko.

March 28, 2012

Re: [Pharo-project] FileURL don't works properly on windows

by Igor Stasenko

On 27 March 2012 18:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote: > >> this part is closely related to command-line arguments handling.. >> >> on windows things, which expected to work, like: >> >> vm image.image <pathToScript>.st >> >> fails to find the script, because it messing up with back/forward >> slashes in path >> and at the end it transforms an input into escaped slashes, which is >> of course cannot be found in file system... > > > right now we use Urls there because it supports to add URL as a "file". > > vm imageimage http://myscript.com/phato.st > > I personally think we should remove that. If you want to load a file via the network, just > write a local script that does that. > > If we remove the network support for script parameters, we will directly solve that problem. > (and we simplify the whole startup logic, and we make the startup not depend on networking). > > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4057 > > Â Â Â Â Marcus > agree.. this thing is a bit overengineeeeered. but in overall it is cool to have, unless it breaks a most basic usage : hey ... a stupid file name passed as an argument! we can remove it, of course, but it won't make a FileURL a bit less broken.. since things like that: 'c:\myfile.txt' asURL retrieveContents still won't work. we should cover it by tests btw, since now we have windows.. but in order to run any test(s) we should fix this thing first :) > > -- > Marcus Denker -- http://marcusdenker.de > -- Best regards, Igor Stasenko.

March 28, 2012

Re: [Pharo-project] Source code comments in Pharo: lots of missing things

by Marcus Denker

On Mar 27, 2012, at 6:32 PM, phil(a)highoctane.be wrote: > Quite a few in morphic for example aren't commented anymore. > Which ones? It's you need to be specific else we will not be able to do any action. Marcus -- Marcus Denker -- http://marcusdenker.de

March 28, 2012