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

Re: [Pharo-project] Debugging code with morphic leads to freezes and a weird message

by StÃ©phane Ducasse

It would be good to publish the fix for other OB 1.4 users (I do not know who is in charge) Stef On Jun 25, 2012, at 9:45 AM, phil(a)highoctane.be wrote: > Oh, okay, thanks a lot!. Lesson taken: check for implementers :) > > 2012/6/25 Marcus Denker <marcus.denker(a)inria.fr> > > On Jun 24, 2012, at 9:39 PM, phil(a)highoctane.be wrote: > > > While debugging actions behind buttons, I do get Project class>>spawnNewProcessIfThisIsUI: not being understood. > > > > This prevents from debugging interactions properly. > > > > And sometimes I get the dreaded "Computation Terminated" message, effectively locking me out of the image (nothing moves anymore, I've got to kill the process). > > > > Ideas on how to fix? This is 1.4 14438 > > > > > > #spawnNewProcessIfThisIsUI: has been moved to UIManager.... it seems that OB still calls it on Project. > > Marcus > > > > -- > Marcus Denker -- http://marcusdenker.de > > > > > >

June 25, 2012

Re: [Pharo-project] Sticky morph after progress morph use

by StÃ©phane Ducasse

Hi hilaire we do not know (at least I do not know what happened with the old progress bar). Now in 2.0 it is fixed (yes I know that you need a 1.4 version). Stef On Jun 24, 2012, at 12:14 PM, Hilaire Fernandes wrote: > Hello, > > With Pharo 1.4 I already reported about it, but when I build a drgeo > image then do a small clean up like this: > > === clean up ==== > FreeTypeFontProvider unload. > ScriptLoader new cleanUpForProduction. > StrikeFont cleanUp. > > (MCPackage named: 'Announcements-Help') unload. > (MCPackage named: 'FileSystem-Tests-Disk') unload. > (MCPackage named: 'FileSystem-Tests-Memory') unload. > (MCPackage named: 'FileSystem-Tests-Core') unload. > (MCPackage named: 'FileSystem-Tests-AnsiStreams') unload. > (MCPackage named: 'Metacello-Help') unload. > (MCPackage named: 'Regex-Help') unload. > RecentMessageList cleanUp. > Smalltalk removeEmptyMessageCategories. > Smalltalk garbageCollect > ==== end of clean up === > > > Then, in the cleaned image, in any place where the progress morph is > used, at the end of the progress process, a shaded morph (the background > of the progress morph) remains on screen like a big smelling peace of > shit - screenshot. > > What cleaning I should not do? > > Thanks > > Hilaire > > > -- > Dr. Geo -- http://www.drgeo.eu > <progress-morph-background-like-a-smelling-peace-of-shit.jpg>

June 25, 2012

Re: [Pharo-project] fulltext method search

by Camillo Bruni

On 2012-06-25, at 09:54, phil(a)highoctane.be wrote: > Ok, removed it. So now, I see a "method indexing" progress bar popping for > a while repeatedly :-). > > Well, it works. And I tried it out: > > "this is an instantaneous (~2ms!) search over all method sources" > Search default matchSentence: 'Convert to a String with Characters' > {(ByteArray>>#asString "a CompiledMethod(108265472)")} > > I am looking into how to integrate this with Spotlight [which is really > fantastic and improves productivity a lot!] (I guess I'll do another > binding like Ctrl-Enter instead of Shift-Enter). So, how do you get the > results? Is there a quick way to open the browser on a given CompliedMethod > right away? (Ah! So much to learn.... Sound is working nicely now BTW, got > a couple clues!) AS you saw the #searchSentence: returns a list of possible method matches. l := Search default matchSentence: 'copyFrom:to:' SystemNavigation default browseMessageList: l name: 'Messages with the string "copyFrom:to:"' - Since it is really an early hack, I don't support case sensitive searching. I wonder though if that is really necessary... Since the results are not fully exact (e.g. some false positives are here and there..) - Integration with system announcements is missing (I do not add new methods to the index..) - the code is rather messy (half of it is still in uncategorized :S) - no test coverage yet :D (bad cami, bad cami!!)

June 25, 2012

Re: [Pharo-project] FIleSystemStreams

by Camillo Bruni

Hi Sven, On 2012-06-25, at 12:41, Sven Van Caekenberghe wrote: > All in all the switch to FileSystem is very good. File/Directory manipulation is much improved. > > (But it does create a problem for library/framework writers, like me, that want to remain compatible with 1.3 and 1.4) > > However, when trying to actually use FileSystem and when looking at the current users in the image, I see a problem (coming up) with FIleSystemStreams and its subclasses. > > They should be binary, but they are silently used as character based, either relying on implicit conversions or explicit ones, without proper encoding. This is wrong. Definitely wrong... Anyway for now I will completely remove FileSystemReadStreams since they do not add much value to the system. Even worse, I think with having yet another stream implementation we completely confuse the hell out of people! see: http://code.google.com/p/pharo/issues/detail?id=6132 > Why is there a FileSystemReadStream>>#nextLine ? > Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone of efficient input ? > Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf â¦] methods on a binary stream ? obsolete I would, given that the FileSystemReadStream is going to be removed > Because even with these methods that should not be there, the streams opened by FileSystem cannot be used for simple parsers or renderers, simply because the elementary #next and #nexPut: deal with bytes instead of characters. > > Some time ago, I did a quick experiment by adding ZnCharacterReadStream and ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I include a file out) that solve this problem from my perspective (but they don't allow arbitrary #position[:] hacks). > > Another question is how buffering works (if present at all), since it seems to be hidden in the plugin ? > > What do the FileSystem hackers, Cami, Sean, et al, think about this situation ? :) I vouch for complete removal of said stream implementations and for now rely on the given FileStream + Co classes. When time comes ( I hope very soon ), we should adapt a decent streaming library which cleans up this stupid mess of byte vs char.

June 25, 2012

[Pharo-project] FIleSystemStreams

by Sven Van Caekenberghe

All in all the switch to FileSystem is very good. File/Directory manipulation is much improved. (But it does create a problem for library/framework writers, like me, that want to remain compatible with 1.3 and 1.4) However, when trying to actually use FileSystem and when looking at the current users in the image, I see a problem (coming up) with FIleSystemStreams and its subclasses. They should be binary, but they are silently used as character based, either relying on implicit conversions or explicit ones, without proper encoding. This is wrong. Why is there a FileSystemReadStream>>#nextLine ? Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone of efficient input ? Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf â¦] methods on a binary stream ? Because even with these methods that should not be there, the streams opened by FileSystem cannot be used for simple parsers or renderers, simply because the elementary #next and #nexPut: deal with bytes instead of characters. Some time ago, I did a quick experiment by adding ZnCharacterReadStream and ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I include a file out) that solve this problem from my perspective (but they don't allow arbitrary #position[:] hacks). Another question is how buffering works (if present at all), since it seems to be hidden in the plugin ? What do the FileSystem hackers, Cami, Sean, et al, think about this situation ? Sven

June 25, 2012

Re: [Pharo-project] Strangest object ever seen?

by Pavel Krivanek

The object is not present in the latest 2.0 image, it was eaten by GC. -- Pavel 23.6.2012 v 9:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > what is the status of this problem? > Because hilaire has some problem with drGeo and we should check how to help him. > > Stef > On May 8, 2012, at 11:49 PM, Pavel Krivanek wrote: > >> Hi, >> >> If you take the latest Pharo 2.0 image from Jenkins (20059) and you execute the expression: >> >> (Metaclass allInstances select: [:c | c superclass = ProtoObject class]) inspect >> >> you will get an collection inspector where the first object is very strange one. It is very hard to get any useful information about the origin of this evil object. The only thing we know exactly is that it causes virtual machine segmentation faults while trying to export class ScrollBar via Fuel. Not only CogVM but even StackVM. >> >> Can you, please, try to help us to get as much information as possible about this object? I named it "dzindzik" :-) >> >> Cheers, >> -- Pavel > >

June 25, 2012

Re: [Pharo-project] Where is the PBE VM?

by Damien Cassou

On Sun, Jun 24, 2012 at 11:55 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Maybe the solution is simply to pick one and make it the most prominent > download link on the PBE web page, either demoting or entirely eliminating > the image-only/latest-Pharo links ok, pharobyexample.org now has a link to the one click image. Best, -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 25, 2012

[Pharo-project] updating 2.0 is broken

by Marcus Denker

'Could not load FileSystem-Tests-Core-SeanDeNigris.18.mcz: ZnHttpUnsuccessful: 404 Not Found' http://code.google.com/p/pharo/issues/detail?id=6152 -- Marcus Denker -- http://marcusdenker.de

June 25, 2012

Re: [Pharo-project] Is it possible to open up two / multiple window surfaces on demand

by Henrik Sperre Johansen

On 25.06.2012 09:09, S Krish wrote: > > I am looking for a VM support to open up on configuration atleast 2 if > not more as possible windows ( surfaces to paint morphs on). > > Viz: I run the dev code / browsers etc on one panel and designate the > other window as the runtime panel to popup runtime windows only I think the closest anyone has been lately is Todd Blanchard, see http://forum.world.st/Native-Windows-td1303058.html . IIRC, the VM-level support needed by FFenestri is only implemented on OSX though. Cheers, Henry

June 25, 2012

Re: [Pharo-project] fulltext method search

by Esteban Lorenzano

Did you changed OB? don't forget to commit changes to the PharoOB repository :) On Jun 25, 2012, at 9:53 AM, phil(a)highoctane.be wrote: > Ok, removed it. So now, I see a "method indexing" progress bar popping for a while repeatedly :-). > > Well, it works. And I tried it out: > > "this is an instantaneous (~2ms!) search over all method sources" > Search default matchSentence: 'Convert to a String with Characters' {(ByteArray>>#asString "a CompiledMethod(108265472)")} > > I am looking into how to integrate this with Spotlight [which is really fantastic and improves productivity a lot!] (I guess I'll do another binding like Ctrl-Enter instead of Shift-Enter). So, how do you get the results? Is there a quick way to open the browser on a given CompliedMethod right away? (Ah! So much to learn.... Sound is working nicely now BTW, got a couple clues!) > > Phil > > > 2012/6/25 Camillo Bruni <camillobruni(a)gmail.com> > > not that I would do something fancy :) (and yeas 2.0) > > do:displayingProgress: > > is the only thing I do basically (and you can remove the display... part so it should even work under 1.4 I think) > > > > On 2012-06-25, at 00:38, phil(a)highoctane.be wrote: > > Error is due to the Progress Morph (guess you use the new thing in 2.0) > > > > 2012/6/25 Camillo Bruni <camillobruni(a)gmail.com> > > > >> I was bored today (after yet another kernel panic) so I implemented a quick > >> fulltext search for methods. > >> > >> > >> "this takes around 1.5mins" > >> Search default buildIndex. > >> > >> "this is an instantaneous (~2ms!) search over all method sources" > >> Search default matchSentence: 'Convert to a String with Characters' > >> > >> > >> I think we should integrate that into some kind of "SpotLight" search > >> for accessing the sources much much faster... > >> > >> The current draft is available here: > >> http://smalltalkhub.com/#!/~dh83/spotlight > >> > >> > >> > > >

June 25, 2012