March 2012 - Pharo-dev - lists.pharo.org

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 27, 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 27, 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 27, 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 27, 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 27, 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 27, 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 27, 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 27, 2012

Re: [Pharo-project] Pharo on iOS w/ faster graphics

by StÃ©phane Ducasse

Hi jeff welcome :) > First, here's a little background about myself. I'm an academic researcher in human-computer interaction and educational technology. I've been programming in Smalltalk since the early days of Squeak. For those who remember, I wrote Swiki. I do :) > I'm now doing work on multi-touch interfaces, such as interactive tabletops and tablets. There's a huge difference between designing interfaces for mouse / keyboard and designing for multi-touch. My current research interests are in creating interfaces that are optimized for the latter, rather than the former. Smalltalk is a great environment for that, because you really can rebuild the GUI from the ground up. I've gone ahead and worked off the work that John McIntosh did on iSqueak to create several applications for iPad. Just that you know we started to clean the event handling because we especially want to support the extension of event handling. Note that if you have enhancements please send them because we always want to improve our infrastructure. > I'm thinking of transitioning from Squeak to Pharo as the current development state of Pharo is a bit cleaner than Squeak. a lot more :) > I'm glad to see that there is some interest in getting Pharo on iOS (though there do seem to be problem). I'm not an Objective-C or C expert, so I wouldn't be good at getting the VM to work, but I would be able to go from there to creating some interesting widgets, frameworks, and apps that I could share with the community. ESUG supported esteban and hilaire for pushing the iPad handling. > One major hurdle I see in my work is that Morphic is just too slow on iPads. While I have been able to optimize the speed of my applications to have them work on Morphic, it is a lot of extra work and I may eventually get to a point where it won't work for what I need it to do. We should optimize it. We hope that by cleaning we will get there. > Is there some sort of magic bullet for addressing this? Cairo? Does anyone have any recommendations for addressing this inside Pharo? I'm not interested in 3D interfaces, but rather fast 2D interfaces. Any advice would be greatly appreciated. > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick

March 27, 2012

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

by phil＠highoctane.be

Quite a few in morphic for example aren't commented anymore. Phil Le 27 mars 2012 18:28, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> a Ã©crit : > > On Mar 27, 2012, at 4:58 PM, philippe.back(a)highoctane.be wrote: > > > Just a question: while looking at the comments for classes in the > browser, there are often missing entries, even for pretty classic classes. > How comes? > > Because the classes were not commented. > > > I find myself with a Squeak image running in parallel just to look up > some content. So, content that makes sense is available but didn't got > carried over to pharo. > > Which classes? > Because we improved this aspect. > > > Is this a licencing issue? Something else? I have pharo1.0.sources so > comments do show where they are available. > > Also, some methods look like a decompile with t1 t2.. > > Strange normally we do not have decompiled code. > > > where the source exists in Squeak with the proper parameters. > > > > Thanks in advance for shining some light in the topic. > > Stef >

March 27, 2012