August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] building from PharoKernel

by Mariano Martinez Peck

For DrGeo I don't think it makes that much sense since you need Morphic and all its friends. So maybe it is just easier to unload some unused packages from PharoCore. For seaside/SmallHarbour it makes much sense, but you should not start from PharoKernel but from the PharoKernel that contains Zinc, Gofer and all the netwroking, otherwise it would be useless for seaside I guess. Since you don't need morphic (unless you want RFB), you can really make much smaller images, which I guess is VERY important for a project like SmallHarbour where you will deploy a lot of images. On Tue, Aug 2, 2011 at 5:01 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > > On Tue, Aug 2, 2011 at 3:41 PM, Hilaire Fernandes < > hilaire.fernandes(a)edu.ge.ch> wrote: > >> I would like to build a DrGeo image from PharoKernel. Is it something >> possible? I guess I am not the only one wondering about that >> > > > I'm interested, but for Seaside / SmallHarbour. > > Laurent. > > > >> >> Hilaire >> >> >> -- >> Education 0.2 -- http://blog.ofset.org/hilaire >> >> >> > -- Mariano http://marianopeck.wordpress.com

Aug. 2, 2011

Re: [Pharo-project] Disable the debugger

by Mariano Martinez Peck

Check in older Pharo images like 1.1.1 all the stuff in #disableProgrammerFacilities disableProgrammerFacilities "Warning: do not call this lightly! It disables all access to menus, debuggers, halos. There is no guaranteed return from this, which is to say, you cannot necessarily reenable these things once they are disabled -- you can only use whatever the UI of the current project affords, and you cannot even snapshot -- you can only quit. You can completely reverse the work of this method by calling the dual Preferences method enableProgrammerFacilities, provided you have left yourself leeway to bring about a call to that method. (does not reverse the ToolSet registrations) To set up a system that will come up in such a state, you have to request the snapshot in the same breath as you disable the programmer facilities. To do this, put the following line into the 'do' menu and then evaluate it from that 'do' menu: Preferences disableProgrammerFacilities. You will be prompted for a new image name under which to save the resulting image." self deprecated: 'No replacement for now'. Beeper beep. (self confirm: 'CAUTION!! This is a drastic step! Do you really want to do this?') ifFalse: [Beeper beep. ^self inform: 'whew!']. self disable: #cmdDotEnabled. "No user-interrupt-into-debugger" self disable: #editableStringMorphs. "turn off shift-click editing" ToolSet registeredClasses copy do: [:c | ToolSet unregister: c]. ToolSet default: nil. "unregister and make sure default is nil to really prevent debug windows" "also now takes care of low space watcher interrupts" self compileHardCodedPref: #cmdGesturesEnabled enable: false. "No halos, etc." self compileHardCodedPref: #cmdKeysInText enable: false. "No user commands invokable via cmd-key combos in text editor" self enable: #noviceMode. "No control-menu" self disable: #warnIfNoSourcesFile. self disable: #warnIfNoChangesFile. Smalltalk saveAs On Tue, Aug 2, 2011 at 5:59 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Hi, > > is it possible to disable the debugger in a Seaside image for production ? > > Laurent Laffont - @lolgzs <http://twitter.com/#%21/lolgzs> > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > Developer group: http://cara74.seasidehosting.st > > -- Mariano http://marianopeck.wordpress.com

Aug. 2, 2011

Re: [Pharo-project] Polymorph improvements

by GermÃ¡n Arduino

Very nice! 2011/8/2 Gary Chambers <gazzaguru2(a)btinternet.com>: > Screenshot of part of project: > http://www.flickr.com/photos/12018791@N06/6001799235/in/photostream > Regards, Gary > > ----- Original Message ----- > From: Gary Chambers > To: Pharo Development > Sent: Tuesday, August 02, 2011 4:40 PM > Subject: [Pharo-project] Polymorph improvements > Hi all. > > I've added an issue with some tweaks/improvements to a few Polymorph > classes. > > http://code.google.com/p/pharo/issues/detail?id=4590 > > Groupboxes can now have dynamic content (model/getContentSelector based). > Abaility to create icon lists via builder/TEasilyThemed. > Expander labels now LabelMorphs rather than TextMorphs (can therefore appear > as disabled) > IncrementalSliderMorphs now honour minWidth/minHeight in layouts > Panel morphs allow event based mouse over handling (call to super was > missing). > Label groups allow for nil labels (equates to empty string) > Regards, Gary >

Aug. 2, 2011

[Pharo-project] Disable the debugger

by laurent laffont

Hi, is it possible to disable the debugger in a Seaside image for production ? Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

Aug. 2, 2011

Re: [Pharo-project] Polymorph improvements

by Gary Chambers

Screenshot of part of project: http://www.flickr.com/photos/12018791@N06/6001799235/in/photostream Regards, Gary ----- Original Message ----- From: Gary Chambers To: Pharo Development Sent: Tuesday, August 02, 2011 4:40 PM Subject: [Pharo-project] Polymorph improvements Hi all. I've added an issue with some tweaks/improvements to a few Polymorph classes. http://code.google.com/p/pharo/issues/detail?id=4590 Groupboxes can now have dynamic content (model/getContentSelector based). Abaility to create icon lists via builder/TEasilyThemed. Expander labels now LabelMorphs rather than TextMorphs (can therefore appear as disabled) IncrementalSliderMorphs now honour minWidth/minHeight in layouts Panel morphs allow event based mouse over handling (call to super was missing). Label groups allow for nil labels (equates to empty string) Regards, Gary

Aug. 2, 2011

[Pharo-project] Polymorph improvements

by Gary Chambers

Hi all. I've added an issue with some tweaks/improvements to a few Polymorph classes. http://code.google.com/p/pharo/issues/detail?id=4590 Groupboxes can now have dynamic content (model/getContentSelector based). Abaility to create icon lists via builder/TEasilyThemed. Expander labels now LabelMorphs rather than TextMorphs (can therefore appear as disabled) IncrementalSliderMorphs now honour minWidth/minHeight in layouts Panel morphs allow event based mouse over handling (call to super was missing). Label groups allow for nil labels (equates to empty string) Regards, Gary

Aug. 2, 2011

Re: [Pharo-project] identityHash bits not incremented for new objects?

by David T. Lewis

On Tue, Aug 02, 2011 at 03:31:30PM +0200, Henrik Johansen wrote: > > On Aug 2, 2011, at 3:14 15PM, Igor Stasenko wrote: > > > On 2 August 2011 14:18, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> > >> On Aug 1, 2011, at 8:43 53AM, Igor Stasenko wrote: > >> > >>> I found that #testBecomeIdentityHash sometimes failing, sometimes not. > >>> > >>> It seems like VM 'forgets' to produce different identityHash bits for > >>> two consequently allocated objects, > >>> while test assumes that they are always different. > >>> > >>> If i insert a statement (see the code), test no longer fails. > >>> > >>> testBecomeIdentityHash > >>> "Note. The identity hash of both objects seems to change after the become:" > >>> > >>> | a b c d | > >>> > >>> a := 'ab' copy. > >>> b := 'cd' copy. > >>> > >>>>>> [ b identityHash = a identityHash ] whileTrue: [ b := b copy ]. > >>> > >>> c := a. > >>> d := b. > >>> > >>> a become: b. > >>> > >>> self > >>> assert: a identityHash = c identityHash; > >>> assert: b identityHash = d identityHash; > >>> deny: a identityHash = b identityHash. > >>> > >>> A simple piece of code reveals the problem: > >>> > >>> (1 to: 20) collect: [:i | > >>> 'ab' copy basicIdentityHash ] #(954 954 955 955 956 956 957 957 958 > >>> 958 959 959 960 960 961 961 962 962 963 963) > >>> > >>> > >>> -- > >>> Best regards, > >>> Igor Stasenko AKA sig. > >> > >> What is the point of this test in the first place? > >> To me it seems to test whether a VM's implementation of become: adheres to some properties. > >> At least, VM bugs in traversal of references during become is the only way I could see the two first asserts EVER being false. > >> > >> As for the last assert (well, deny actually), in the context of what it's supposed to test as established above, it seems to me to say a VM should never give the same identityHash to subsequently copied objects. Which means > >> a) It has nothing to do with become and identityHash, thus is in the test. > >> b) Is this a property any code actually rely on? > >> > >> If not, why would we assert such a restriction on the VM implementation, or is it harmless? > >> > >> Either way, modifying the test to iterate till they ARE different, would make it meaningless in either case (and possible infinite loop in case of a really bad VM). > >> > > > > There is strong reason to test identityHashes, because VM should > > preserve an identity hash for oops. > > > > But of course test is wrong , because to test that , it should be like > > following: > > > > | a b hash1 hash2 | > > > > a := 'ab' copy. > > b := 'cd' copy. > > hash1 := a identityHash. > > hash2 := b identityHash. > > > > a become: b. > > > > self > > assert: a identityHash = hash1; > > assert: b identityHash = hash2. > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > Please include a comment with that. :) > Like this has shown, it's rather hard to know wtf to do when you can't unambiguously read what its actually intended to test from the code itself. Henry, FYI Igor has found a small but important bug in the VM. There is some additional follow up discussion on the vm-dev list that you can read starting here: <http://lists.squeakfoundation.org/pipermail/vm-dev/2011-August/009006.html> Dave

Aug. 2, 2011

Re: [Pharo-project] building from PharoKernel

by laurent laffont

On Tue, Aug 2, 2011 at 3:41 PM, Hilaire Fernandes < hilaire.fernandes(a)edu.ge.ch> wrote: > I would like to build a DrGeo image from PharoKernel. Is it something > possible? I guess I am not the only one wondering about that > I'm interested, but for Seaside / SmallHarbour. Laurent. > > Hilaire > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > > >

Aug. 2, 2011

Re: [Pharo-project] identityHash bits not incremented for new objects?

by Igor Stasenko

On 2 August 2011 15:31, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Aug 2, 2011, at 3:14 15PM, Igor Stasenko wrote: > >> On 2 August 2011 14:18, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On Aug 1, 2011, at 8:43 53AM, Igor Stasenko wrote: >>> >>>> I found that #testBecomeIdentityHash sometimes failing, sometimes not. >>>> >>>> It seems like VM 'forgets' to produce different identityHash bits for >>>> two consequently allocated objects, >>>> while test assumes that they are always different. >>>> >>>> If i insert a statement (see the code), test no longer fails. >>>> >>>> testBecomeIdentityHash >>>> Â Â Â "Note. The identity hash of both objects seems to change after the become:" >>>> >>>> Â Â Â | a b c d | >>>> >>>> Â Â Â a := 'ab' copy. >>>> Â Â Â b := 'cd' copy. >>>> >>>>>>> Â Â [ b identityHash = a identityHash ] whileTrue: [ b := b copy ]. >>>> >>>> Â Â Â c := a. >>>> Â Â Â d := b. >>>> >>>> Â Â Â a become: b. >>>> >>>> Â Â Â self >>>> Â Â Â Â Â Â Â assert: a identityHash = c identityHash; >>>> Â Â Â Â Â Â Â assert: b identityHash = d identityHash; >>>> Â Â Â Â Â Â Â deny: a identityHash = b identityHash. >>>> >>>> A simple piece of code reveals the problem: >>>> >>>> (1 to: 20) collect: [:i | >>>> Â Â Â 'ab' copy basicIdentityHash ] #(954 954 955 955 956 956 957 957 958 >>>> 958 959 959 960 960 961 961 962 962 963 963) >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>> >>> What is the point of this test in the first place? >>> To me it seems to test whether a VM's implementation of become: adheres to some properties. >>> At least, VM bugs in traversal of references during become is the only way I could see the two first asserts EVER being false. >>> >>> As for the last assert (well, deny actually), in the context of what it's supposed to test as established above, it seems to me to say a VM should never give the same identityHash to subsequently copied objects. Which means >>> a) It has nothing to do with become and identityHash, thus is in the test. >>> b) Is this a property any code actually rely on? >>> >>> If not, why would we assert such a restriction on the VM implementation, or is it harmless? >>> >>> Either way, modifying the test to iterate till they ARE different, would make it meaningless in either case (and possible infinite loop in case of a really bad VM). >>> >> >> There is strong reason to test identityHashes, because VM should >> preserve an identity hash for oops. >> >> But of course test is wrong , because to test that , it should be like >> following: >> >> Â Â | a b hash1 hash2 | >> >> Â Â Â a := 'ab' copy. >> Â Â Â b := 'cd' copy. >> Â hash1 := a identityHash. >> Â hash2 := b identityHash. >> >> Â a become: b. >> >> Â Â Â self >> Â Â Â Â assert: a identityHash = hash1; >> Â Â Â Â assert: b identityHash = hash2. >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > Please include a comment with that. :) > Like this has shown, it's rather hard to know wtf to do when you can't unambiguously read what its actually intended to test from the code itself. > The intent for preserving a hash is to not break hashed collections which using identityhash: a := 'aver' copy. dict := IdentityDictionary new. dict at: a put: 10. a become: 'ijoewfj' copy. self assert: (dict at: a) = 10 > Cheers, > Henry > > > -- Best regards, Igor Stasenko AKA sig.

Aug. 2, 2011

[Pharo-project] building from PharoKernel

by Hilaire Fernandes

I would like to build a DrGeo image from PharoKernel. Is it something possible? I guess I am not the only one wondering about that Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

Aug. 2, 2011