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

Re: [Pharo-dev] [squeak-dev] Re-purposing vm parameter 23 in Spur?

by John McIntosh

23 was used in os 7/8/9? back in the last millennium to ensure the allocation of memory for the image wouldn't consume all the memory in the application space, thus leaving no memory for third party plugs which could required non-trival free memory for malloc. So yes a good reuse.. Also see http://en.wikipedia.org/wiki/Mac_OS_memory_management On Mon, Mar 23, 2015 at 12:45 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > right now vm parameter 23 is defined to be: > > 23 bytes of extra memory to reserve for VM buffers, plugins, etc. > > but is ignored by all the VMs (AFAIA). I would like to reinterpret this > in Spur to be the minimum amount of headroom to make available on startup. > I expect this is useful for really small platforms where one wants to > control the ammount of free space on startup to be quite small. Given that > the field is ignored I like putting it to a more useful purpose. > Objections? > -- > best, > Eliot > > > > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> https://www.linkedin.com/in/smalltalk ===========================================================================

March 23, 2015

Re: [Pharo-dev] UI Workflows Are Like Snowflakes

by stepharo

Sean I have no problem to discuss. Now I had 35 methods in 35 different classes to slightly changes and we should be able to avoid to select and click all the times. Stef Le 23/3/15 18:48, Sean P. DeNigris a Ã©crit : > Marcus Denker-4 wrote >> In general, the idea of "you have to ask and get the ok from the list for >> every change" is dangerous... the Smalltalk people are *extremely* >> conservative > NB: I said "IDE UI workflow changes", which seem to be a relatively small > percentage of the overall changes, but seem to cause the most disruption. > > I know that you guys had a rough time trying to make progress before the > fork. I understand that Pharo has a big dream and that there will be > worthwhile pain getting there. > > If we can't agree to discuss the most high-risk, low frequency changes, how > about at least a dev list notification about those particular changes? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234p4814460.ht… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > >

March 23, 2015

Re: [Pharo-dev] Morphs becoming unresponsive

by Guillermo Polito

WOOOOW, Thanks!!!!! El lun., 23 de mar. de 2015 a la(s) 9:29 p. m., stepharo <stepharo(a)free.fr> escribiÃ³: > + 1 > Thanks Henrik!!! > > Le 23/3/15 16:17, Ben Coman a Ã©crit : > > > > On Mon, Mar 23, 2015 at 9:06 PM, Henrik Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> I just ran into a case where all morphs became unresponsive, and clicking >> anywhere only gave me the World Menu. >> >> After some investigation, it turned out all the World submorphs had been >> locked, and I could "unfreeze" them with the following (from a new >> Workspace): >> World submorphsDo: [ :aMorph | aMorph unlock ] >> >> What triggered it? >> Well, the image had become unresponsive, so I clicked the close buttons a >> couple of times (before trying good ol' cmd-dot, which brought up a >> debugger on the old UI process and let me continue). >> >> The close dialog is modal, normally that's no problem, since the modal >> morph locks all other morphs, no two can be opened at the same time (unless >> you somehow let that modal morph open another), but the close triggered by >> the system window's close button is special, since it is triggered outside >> the control of the World. >> >> The bug is rare in occurrence, yet easy to trigger; press the window >> close button twice, cancel one of the close dialogs, all windows that were >> open will remain locked and seem unresponsive. >> >> It might be smart to rethink the whole modality concept to make the code >> more robust/coherent, but for now an extra check for this single case in >> PasteUpMorph >> windowEvent: (for instance, using a morph property) should >> do the trick, I'll submit a slice shortly. >> >> Cheers, >> Henry >> > > Nice find. I've been hit by this a few times and been clueless. > cheers -ben > > >

March 23, 2015

Re: [Pharo-dev] UI Workflows Are Like Snowflakes

by stepharo

I do not see how discussing the fact that we could via a trick (I failed to find it) navigate methods in the same name in other classes without having to click on the class, catgeory and methods would have solve the problem that I introduced a bug while trying to add this extra behavior? Then you do not understand my point: I integrated the scroll fix from jan because a change was breaking their flow. And ??? How can I possibly know that it would break your fixes that apparently broke their flow. You see what I mean? I could also simply ignore issue that I do not know or contributed too but it would slow down the process, isn't? Stef > stepharo wrote >> Could you stop crying because this is a bit boring? > Could you address my policy suggestion instead of crying? ;) It would've > taken the same amount of time to answer my message productively instead of > lawyering it by pointing out the one example out of three that you could > turn back around on me and ignoring everything else. > > > stepharo wrote >> So instead of crying help. > I've participated in fixing hundreds of issues, and that's just on the new > issue tracker. Is that a reasonable comment? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234p4814344.ht… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

March 23, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 395d15: 40577

by stepharo

> >> On 23 Mar 2015, at 18:35, Andrei Chis <chisvasileandrei(a)gmail.com >> <mailto:chisvasileandrei@gmail.com>> wrote: >> >> Can you notify me when a slice related to rubric is integrated. >> I need to merge it back to the Rubric repo. >> > > Yesâ¦. I wanted to commit this but I have no rights. (this external > repo stuff is really complex and slow) Too much I would say. >> >> Cheers, >> Andrei >> >> >> On Mon, Mar 23, 2015 at 4:28 PM, GitHub <noreply(a)github.com >> <mailto:noreply@github.com>> wrote: >> >> Branch: refs/heads/4.0 >> Home: https://github.com/pharo-project/pharo-core >> Commit: 395d1598748873bf4a4d1c194585e53f2821216c >> https://github.com/pharo-project/pharo-core/commit/395d1598748873bf4a4d1c19… >> Author: Jenkins Build Server <board(a)pharo-project.org >> <mailto:board@pharo-project.org>> >> Date: 2015-03-23 (Mon, 23 Mar 2015) >> >> Changed paths: >> M >> Rubric.package/RubEditingMode.class/class/menu/extendedSearchMenuOn_.st >> R ScriptLoader40.package/ScriptLoader.class/instance/pharo - >> scripts/script576.st <http://script576.st/> >> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - >> scripts/script577.st <http://script577.st/> >> R ScriptLoader40.package/ScriptLoader.class/instance/pharo - >> updates/update40576.st <http://update40576.st/> >> A ScriptLoader40.package/ScriptLoader.class/instance/pharo - >> updates/update40577.st <http://update40577.st/> >> M >> ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >> M >> Slot.package/SlotClassBuilder.class/instance/initialize-release/build.st >> <http://build.st/> >> M >> Slot.package/SlotClassBuilder.class/instance/initialize-release/buildNewClass.st >> A >> Traits.package/TClassDescription.class/instance/slots/slotNamed_ifFound_.st >> A >> Traits.package/TClassDescription.class/instance/slots/slotNamed_ifFound_ifNone_.st >> A >> Traits.package/TraitDescription.class/instance/slots/slotNamed_ifFound_.st >> A >> Traits.package/TraitDescription.class/instance/slots/slotNamed_ifFound_ifNone_.st >> >> Log Message: >> ----------- >> 40577 >> 15190 Nautilus incorrectly flags Error classes as "missing class >> comments" >> https://pharo.fogbugz.com/f/cases/15190 >> >> >> >> 14924 Failing tests: >> testClassDescriptionRespectsPolymorphismWithTraitDescription >> https://pharo.fogbugz.com/f/cases/14924 >> >> 15189 "Extended search" vs. "Code search" >> https://pharo.fogbugz.com/f/cases/15189 >> >> http://files.pharo.org/image/40/40577.zip >> >> >> >

March 23, 2015

Re: [Pharo-dev] Morphs becoming unresponsive

by stepharo

+ 1 Thanks Henrik!!! Le 23/3/15 16:17, Ben Coman a Ã©crit : > > > On Mon, Mar 23, 2015 at 9:06 PM, Henrik Johansen > <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> > wrote: > > I just ran into a case where all morphs became unresponsive, and > clicking anywhere only gave me the World Menu. > > After some investigation, it turned out all the World submorphs > had been locked, and I could "unfreeze" them with the following > (from a new Workspace): > World submorphsDo: [ :aMorph | aMorph unlock ] > > What triggered it? > Well, the image had become unresponsive, so I clicked the close > buttons a couple of times (before trying good ol' cmd-dot, which > brought up a debugger on the old UI process and let me continue). > > The close dialog is modal, normally that's no problem, since the > modal morph locks all other morphs, no two can be opened at the > same time (unless you somehow let that modal morph open another), > but the close triggered by the system window's close button is > special, since it is triggered outside the control of the World. > > The bug is rare in occurrence, yet easy to trigger; press the > window close button twice, cancel one of the close dialogs, all > windows that were open will remain locked and seem unresponsive. > > It might be smart to rethink the whole modality concept to make > the code more robust/coherent, but for now an extra check for this > single case in PasteUpMorph >> windowEvent: (for instance, using > a morph property) should do the trick, I'll submit a slice shortly. > > Cheers, > Henry > > > Nice find. I've been hit by this a few times and been clueless. > cheers -ben

March 23, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Alain Plantec

thanks a lot for these explanations. yep! very promising :) I would love to see all these improvements implemented in Bloc. > Le 23 mars 2015 Ã 20:54, Aliaksei Syrel <alex.syrel(a)gmail.com> a Ã©crit : > > What we really want to have in Bloc is an easy way to detect that user clicked outside of specific morph. I will investigate this Cheers Alain

March 23, 2015

Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?

by stepharo

Why do you start fun discussion when I'm not connected :). I like the idea of the distinction between archive and supported. I like archives :)

March 23, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Tudor Girba

Thanks for this reply, Alex. Doru On Mon, Mar 23, 2015 at 8:54 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > Sorry if my reply will be too long, but I tried to summarise our > experience with Morphic/Brick and give some useful feedback or even provide > ideas. Who wants will read :) > > Brick is not a thin layer anymore. > > It depends on what you mean under 'a thin layer' ;) Anyway, Brick was born > out of need. Spotter is completely built using Brick and Rubric. No morphs > are used at all (except Rubric of course). All Bricks in Spotter in the end > are subclasses of GLMBrick, which uses from original Morph only Canvas > (without drawing) and MorphicEvents. Everything else was rewritten from > scratch. During some period of time Brick was able to render itself on > Athens canvas, but we dropped it because of Font issues in athens. > Spotter is not the only tool written using Brick, GLMPager - a pane pager > in GT-Inspector, GT-Playground and GT-Debugger is also completely done > using Brick. Almost all tab labels and tab selector in GT tools are Bricks. > > I could say that we collected quite some experience building it. Now I > would like to enumerate features of UI framework we used to solve > encountered problems. > > > - Local bound coordinates. > > Nothing to say more here :) It's somehow obvious to have. > > > - Detects graph of Bricks that should be invalidated when Brick > triggers invalidation. So there is no need to invalidate the whole graph. > - For example if Brick fills parent it means that it doesn't depend > on children (simple and most common situation). So if any child triggers > invalidation there is no need to invalidate parent as it doesn't depend on > them. The same works in reversed way. > - Build graph separately for each dimension: width and height. If > only height of Brick was changed and children depend only on width, there > is no need to invalidate them => x2 faster. > - Invalidate resizing and re layouting separately. If there is no > need to reposition bricks when size changes we just skip it. > > > - Link subbricks in a DoubleLinked list. So subbrickAfter and > subbrickBefore could be done in O(1). Morphic does it in O(n). It iterates > over the whole submorphs collection of the owner finds index if current > morph and then returns submorphs at: index +/-1. submorphAfter is used when > morphic tries to detect which morph should take focus. Take a look at: > Morph>>nextMorphWantingFocus. It iterates over owner's subbricks and for > each asks submorphAfter (O(n)) - resulting time O(n^2)! That is why opening > a window with a lot of submorphs takes so many time, especially system > browser for big classes. > > > - Native support of *paddings* with css-like syntax: > > padding: anArrayOrInteger > > paddingTop: anInteger >> paddingRight: anInteger >> paddingBottom: anInteger >> paddingLeft: anInteger > > > padding: 10. "top, right, bottom, left padding are 10px" > > padding: #(10 20). "top, bottom padding 10px. left, right padding 20px" > > padding: #(10 20 30). "top 10px. left, right 20px. bottom 30px" > > padding: #(10 20 30 40). "top 10px, right 20px, bottom 30px, left 40px" > > > - Native support of *margins* with css-like syntax: > > margin: anArrayOrInteger > > marginTop: anInteger >> marginRight: anInteger >> marginBottom: anInteger >> marginLeft: anInteger > > Have the same syntax as padding. > > > - Native support of dynamic *minHeight, minWidth, maxHeight, maxWidth* > > minWidth: anIntegerOrBlock "actually any object that implements >> brickValue:" >> maxHeight: anIntegerOrBlock > > > minHeight: [ : brick | brick label width * 2 ]. > > minHeight: 200. > > maxWidth: [ self height / 2 ]. > > maxWidth: 100. > > > - Native support of *z-index*, so we don't rely on subbricks' order > any more if one brick should be drawn above/below others. Works the same as > css one. > > zIndex: 2. "default value is 1" > > > > - Native support of *floating *bricks. Floating bricks don't > influence on any other neighbour bricks in layout. > > floating: aSymbol > > floating: #right. "top right brick's corner matches top right parent's > corner + corresponding paddings and margins" > > floating: #center. "will be in the center of the parent and doesn't care > about other subbricks" > > Example use case is scroll bar in spotter - it has floating: #right and > zIndex: 2 so it appears above all list elements. (+ some margins to make it > fancy). > > > - Native support of horizontal and vertical *aligning*. > > hAlign: aSymbol > > vAlign: aSymbol > > hAlign: #right. > > vAlign: #center. > > > > - Horizontal and vertical *shrinking* to fit children. It is possible > to have in one brick two subbricks where one shrink wraps and other fills > parent. > > hShrinkWrap. >> vShrinkWrap. > > > > - Horizontal and vertical *filling* with support of percents and > min/max height/width. If in brick one child shrink wraps width (or have > static width) and other fills 100% of parent's width, filling one will take > only available space left by shrinking (or static) brick. > > hSpaceFill: aFloat - fills aFloat percents of parent's width >> hSpaceFill. - alias for 100 percents. >> vSpaceFill: aFloat - fills aFloat percents of parent's height >> vSpaceFill. - alias for 100 percents. > > > > - Transparent *border* styling with possibility to separately > configure each side. > > borderWidth: anArrayOrInteger. >> borderColor: anArrayOrColor > > The same syntax as used for paddings/margins > > > - Native support of smooth gradient *box-shadows* with rounded corners: > > shadowColor: aColor. >> shadowWidth: anInteger. > > > > - Layout events such as: > > onLayouted - "called when brick was completely resized and layouted in >> its parent" > > onChildrenLayouted - "called when all children are completely resized and >> layouted" > > > Use case: implementing flexible and responsive UI. Used in GLMLabelBrick > to shrink text and add '...' when it doesn't fit in parent. Example is tab > labels in Playground. Morphic version of tabs shrinks text and change ui of > the tab during drawing. WAT? > > > - Application dependent themes. To make app work perfect all UI > elements should have the same style. In case of spotter, item preview is > created outside of spotter and there is no way using existing morph theme > mechanism to customize its look&feel especially for spotter, because > widgets always refer to global UITheme. Brick extends theming mechanism and > allows to extend existing themes specifically for needed application and it > will be applied to the whole tree of subbricks. For example spotter can > completely change theme in runtime to dark (without even closing it). > > "in context of SpotterMorph" self themer: GTSpotterBrickDarkThemer new. >> (or just replace first line in initialize) > > Even having white theme chosen in settings. (all rubric fields become dark > too). > > > > - What we really want to have in Bloc is an easy way to detect that > user clicked outside of specific morph. > > > What do you want with brick ? A new framework or just an "implementation >> detail" for spotter? >> It is *really* important to clarify this. > > > Now it becomes more stable, api changes less and less. We already have > quite a number of tests for layouting logic and documentation for basic > widgets. > What we want from brick... I think we want to have a way to build fast and > cheap unique and complex UIs. While it will fit our needs in GT Team we > will use it. We really would like to move all tools to Bloc as soon as > possible, but we just need something right now that works and can be used > in current version. Of course it would be great to cooperate to make Bloc > release sooner. > > Some time ago I tried to port Brick on top of Bloc saving all business > logic untouched and only changing events from morphic ones to bloc and > FormCanvas to AthensCanvas. It was rather successful. I will be happy if it > would be possible to do everything or almost everything mentioned above in > Bloc. I think we will never (but who knows) announce Brick as separate > project. In our minds it is just useful helper library. > > Thanks for reading :) > > Cheers, > Alex > -- www.tudorgirba.com "Every thing has its own flow"

March 23, 2015

Re: [Pharo-dev] [Moose-dev] Re: [Pharo-users] loading Glamour in Pharo 4

by Andrei Chis

One can load a newer version of monticello to be able to force the loading of dependent configurations. Still this would not fix the underlying issue: one cannot update a library from the system without also updating the tools that depend on it. For example, if morphic would be loaded through a configuration you could not load the latest version of morphic without also loading the latest version of all the tools. The best solution could be to not depend on glamour #development unless really needed. Cheers, Andrei On Mon, Mar 23, 2015 at 9:06 PM, stephan <stephan(a)stack.nl> wrote: > On 23-03-15 20:47, Johan Fabry wrote: > > I think it is pretty telling that 2 different persons basically had the > same issue in 3 days. Should this issue be considered as something to have > fixed for the Pharo 4 release? > > That would be nice. Do we know how it should be fixed? > It is something I expect people to run into rather often. > > Stephan > > > > On Mar 23, 2015, at 14:53, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > > There are several tools in Pharo that depend on Glamour. > If you update glamour to the latest version you also need to update the > tools that depend on it. > > This script updated everything: > > { { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }. > { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. > { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. > { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. > { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. > { 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }. > } do: [ :spec | > Gofer new > smalltalkhubUser: spec second project: spec third; > package: spec first; > load ]. > ConfigurationOfGToolkitCore loadDevelopment. > > If you are interested just in the Roassal presented you could try and > only load the package Glamour-Roassal2-Presentations + Roassal. > However, depending on what changes you might need to also update glamour. > > > Cheers, > Andrei > > > > On Mon, Mar 23, 2015 at 6:47 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> After loading Glamour dev in Pharo 40 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Gofer new >> smalltalkhubUser: 'Moose' project: 'Glamour'; >> package: 'ConfigurationOfGlamour'; >> load. >> (Smalltalk at: #ConfigurationOfGlamour) >> perform: #loadDevelopment >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> when I try opening Playground I get >> AnObsoleteGLMLiveStringBrick(Object)>>doesNotUnderstand: #textLogic: >> >> And Spotter throws >> GLMHintableActionButtonBrick(Object)>>doesNotUnderstand: #addUpAction: >> >> Am I missing some extra dependency? >> >> Thanks, >> Peter >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >

March 23, 2015