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

Re: [Pharo-dev] [vwnc] The Grapher charting engine

by Alexandre Bergel

Hi! > If you're heading to make "Roassal the best visualizing engine of the Universe" then what are your intentions with connecting it to the outer world ? This is a rather broad question :-) While our visualizations are meant to run in a standard Smalltalk environment, they are exportable to HTML. Interaction are also preserved. Here are two simple examples: https://dl.dropboxusercontent.com/u/31543901/TMP/memoryBlueprintExample.html <https://dl.dropboxusercontent.com/u/31543901/TMP/memoryBlueprintExample.html> https://dl.dropboxusercontent.com/u/31543901/online/WebReport/seisms.html <https://dl.dropboxusercontent.com/u/31543901/online/WebReport/seisms.html> And a larger and more complex example is in the file https://dl.dropboxusercontent.com/u/31543901/TMP/ExampleReport.zip <https://dl.dropboxusercontent.com/u/31543901/TMP/ExampleReport.zip> check the file Example.pillar.html > Will it remain a multiplatform toolbox ? Or are you heading towards a BI desktop or Web app ? Roassal will remain closely linked to Smalltalk (VisualWorks & Pharo). Cheers, Alexandre > > Regards, > > Maarten MOSTERT > > > > 28 Av Alphonse Denis > 83400 HyÃ¨res, France > +33 676411296 > http://stakepoint.com/ <http://stakepoint.com/> > > > > > "Alexandre Bergel" <alexandre.bergel(a)me.com> | > > Dear all, > > As many of you know, Grapher is a Ã¼ber-cool charting engine, part of Roassal. > For people who do not know what Grapher is, here is a (compelling we hope) example: > <855A292C-DE42-4FF5-83ED-49477CDAA250.png> > Which is obtained by the following script: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > | b colors points ds pts dec lb | > b := RTGrapher new. > colors := Array with: Color red with: Color blue. > points := OrderedCollection new. > > colors do: [ :c | > ds := RTStackedDataSet new. > pts := ((1 to: 100) collect: [ :i | 50 atRandom - 25 ]) cumsum. > points add: pts. > ds points: pts. > dec := RTDevVarDecorator new. > dec moveBehind; > desviation: 0.5; > color: (c alpha: 0.3); > points: pts. > ds connectUsing: (RTLine new color: (c alpha: 0.5); width: 1 ). > b add: ds. > b addDecorator: dec. > ]. > > b axisX; axisY. > b build. > > lb := RTLegendBuilder new. > lb view: b view. > colors doWithIndex: [ :c :i | > lb addColor: c text: 'Series ', i printString ]. > lb build. > b view @ RTZoomableView. > b view > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > In our grand vision of making Roassal the best visualizing engine of the Universe (we also know to be modest time to time, but not today :-), Grapher will play a very important role. We would like to stabilize Grapher and make it sure it happily fits everybody needs. You can help on it: > > - When you are tempted to look at the dark side of the planet (this is where R, JFreeChart, gnuplot, D3 and all their friends live), let us know. We will make sure to make you are happy again. > > - Share your wishlist with us. We already have a long todo list, but your opinion does matter and will take it seriously > > - we are open to contributions, which could be financial, bug fixe, enhancement, or simply encouragement. > > I am very happy to be surrounded by very smart engineers. Your encouragement are making them happy :-) > > Cheers, > Alexandre, in the name of the Object Profile Team > NB: sorry for the cross-list posting, but this email is very important for us, and for you we hope. > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > <855A292C-DE42-4FF5-83ED-49477CDAA250.png>

March 23, 2015

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

by stephan

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 >> <mailto:chisvasileandrei@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 >> <mailto:i.uhnak@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 <mailto:Moose-dev@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 <http://pleiad.cl/%7Ejfabry> > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

March 23, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Aliaksei Syrel

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

March 23, 2015

Re-purposing vm parameter 23 in Spur?

by Eliot Miranda

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

March 23, 2015

Re: [Pharo-dev] "Suggestions" menu entry not in GTPlayground > Any reason why?

by Damien Cassou

Rename temp, extract temp, extract method (requires class to be supplied) On Mar 22, 2015 11:01 AM, "Tudor Girba" <tudor(a)tudorgirba.com> wrote: > Because I haven't seen a suggestion for the Workspace. Could you give me > concrete examples of suggestions that work in the Workspace? > > Doru > > On Sun, Mar 22, 2015 at 10:14 AM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> Or how to get them back? >> >> TIA >> Phil >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

March 23, 2015

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

by Esteban Lorenzano

Yesâ¦ I was asking to see how can we proceed, because we cannot continue distributing as now. In the course of the conversation I found a solution that will please everyoneâ¦ and will allow us to keep giving also zeroconf scripts without needing to download source versions for all (which was, in fact, the problem I was trying to fix). It will require some file reorganisation and the concept of âblessed vmâ: a version we will distribute with the image version (it will be a vm for pharo1, one for pharo2, etcâ¦ each one with their sourcesâ¦ And yesâ¦ that means a bit more work to configure if you have multiple image-versionsâ¦ but in the long way is the only way we can ensure how an image and a vm works together :) So, no need to continue arguing :) cheers, Esteban > On 23 Mar 2015, at 18:12, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Marcus, > > This makes perfect sense to me ... If zeroconf is only used for the supported versions of Pharo that is perfectly fair ... > > When a version goes off of zeroconf support it would be convenient if one could find the appropriate "eternal download urls" for the image/vm otherwise how would I know? > > Keep in mind, that I use zeroconf to download for travis-based tests and I don't have a physical disk to look at ... and it is possible that I won't know that a particular version has gone off of zeroncof support until my build fails ... so it would be _convenient_ to be able to lookup the image/vm combo that I need to use... > > Dale >> The thing is that get.pharo.org <http://get.pharo.org/> is more than a download. People will expect that it *works*. And we can not (we really can not) support all versions >> of Pharo. E.g. Spur. Soon we will have a VM that can not run old images. If we keep get.pharo.org <http://get.pharo.org/> for 1.4, people expect it to work. And we will have >> to provide a VM for the old version. Then at some point, this VM will not work anymore on the then current linux. Then people expect us to fix that. >> >> Just downloads is a different thing: this is an archive, use it at your own risk. >> >> Marcus >

March 23, 2015

Unique Mouse Wheel Events

by Sean P. DeNigris

Cross-posted to Pharo dev, Squeak dev, and Squeak VM lists (but Pharo list rejected so I am reposting there separately)... Recently, we discovered on the Pharo dev list that the key combination used to fake wheel events - ctrl + arrowKey - may be a bit too simple. Apparently ctrl+horizontalArrowKey is a standard in-use combo in Linux and Windows, so adding horizontal wheel events broke some users' workflows. So I propose "ctrl + alt + shift + cmd + arrowKey". The new combo is: very unlikely to be typed backward-compatible with existing Pharo and Squeak images, which only checks that either cmd or ctrl is pressed frees up ctrl + arrow for our Linux/Windows friends For Pharo, there is: https://github.com/pharo-project/pharo-vm/pull/72 Fogbugz Issue 15209: "Mouse Wheel Events Keyboard Clash", with a slice all ready on the image side once the VM patch is integrated. NB: I changed the combo in the VM for Mac OS and OSX. Are these the only two platforms that fake wheel events? I searched a bit but didn't see similar logic for other platforms... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Unique-Mouse-Wheel-Events-tp4814475.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 23, 2015

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

by Sean P. DeNigris

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] [pharo-project/pharo-core] 395d15: 40577

by Marcus Denker

> On 23 Mar 2015, at 18:35, Andrei Chis <chisvasileandrei(a)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) > > 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 <https://github.com/pharo-project/pharo-core> > Commit: 395d1598748873bf4a4d1c194585e53f2821216c > https://github.com/pharo-project/pharo-core/commit/395d1598748873bf4a4d1c19… <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 <https://pharo.fogbugz.com/f/cases/15190> > > > 14924 Failing tests: testClassDescriptionRespectsPolymorphismWithTraitDescription > https://pharo.fogbugz.com/f/cases/14924 <https://pharo.fogbugz.com/f/cases/14924> > > 15189 "Extended search" vs. "Code search" > https://pharo.fogbugz.com/f/cases/15189 <https://pharo.fogbugz.com/f/cases/15189> > > http://files.pharo.org/image/40/40577.zip <http://files.pharo.org/image/40/40577.zip> > > >

March 23, 2015

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

by Andrei Chis

Can you notify me when a slice related to rubric is integrated. I need to merge it back to the Rubric repo. Cheers, Andrei On Mon, Mar 23, 2015 at 4:28 PM, GitHub <noreply(a)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> > 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 > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/ > script577.st > R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/ > update40576.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/ > update40577.st > M > ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > M Slot.package/SlotClassBuilder.class/instance/initialize-release/ > 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