- Pharo-dev - lists.pharo.org

create snapshots out of github based packages

by Nicolai Hess

Is there any way to create a "snapshot" of a project from a git based repository. Something that creates a "condensed" old style mcz package ? Maybe there is already something and I missed it ? Because now I am just a little shocked how much files are created during loading a project. I did some tests with gtoolkit bloc and calypso. Sure, bloc or gtoollkit may be huge projects, but they produce thousands of files. And I don't mean 1 or 2 thousand files. Loading bloc for example creates over 20.000 files. This is damn slow on windows.

Dec. 10, 2017

loading from github changes lgit classes?

by Nicolai Hess

How come, loading a github project writes strange code change entries for classes like LGitFetchOptions LGitRemoteCallbacks ... For example, in a Pharo 6.1 image I load bloc like this: Metacello new baseline: 'Bloc'; repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; load: #core In my Epicea code change window I see this entries (see screenshot). And the final "new" version of this classes, (class definitions) just look like the original class definition in a fresh image.

Dec. 10, 2017

gtInspector+FastTable enhancement requests

by Ben Coman

Feedback for GT'ers... I'm probably ab-using FastTable support in gtInspector, but as a quick hack during initial prototyping it was *very* nice to be able review retrieved data as a table of instances with a column per instance variable. Some enhancements that would make this even better... 1. Horizontal scroll bar - There are columns past the right margin that I can't get to for lack of one. 2. Column resizing to shift subsequent columns, which could provide another path to seeing the hidden columns. 3. Individual column width auto-fit - like in Excel where you double-click the edge https://www.youtube.com/watch?v=Yeb8emsjtf4 4. All columns auto-fit 5. Auto-fit columns prior to first opening. 6. Being able to split column labels over two lines - to allow for thinner columns For a demonstration, could you please load the attached ST fileout (its small), and also... Gofer it smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo'; configurationOf: 'NeoJSON'; loadStable. Then inspect.... BittrexMarket getAll. cheers -ben

Dec. 10, 2017

Re: [Pharo-dev] How to get rid of empty XML nodes?

by Stephane Ducasse

Norbert Should I say to the tool generating the XML that it is an idiot? Even that I cannot. It is a tool I do not control. I have no control about what I get. Now why we cannot control that if people add a line return or not does not matter? Why I cannot be in charge of deciding? I take the risk of the interpretation but now the "standard" does not help me at all. It just tells me that is good for me. I implemented in the past "standards" like XMI to found that there were bugs in the spec. At then end, each time I visit a node I have to check visitNodeWithElements: aNodeWithElements | currentNode | currentNode := OkStubNode new. self cleanNode: aNodeWithElements. aNodeWithElements hasChildren ifTrue: [ | tokenNode | self cleanNode: aNodeWithElements nodes first. tokenNode := self visitElement: aNodeWithElements nodes first. self assert: tokenNode isToken. currentNode addChild: tokenNode. aNodeWithElements nodes allButFirst do: [ :each | currentNode addChild: (self visitNodeWithElements: each) ] ]. ^ currentNode And I do not like to modify a structure while I'm visiting it. cleanNode: aNodeWithElements aNodeWithElements removeNodes: (aNodeWithElements nodes select: [ :e | e isStringNode and: [ e isEmpty or: [ e isWhitespace ] ] ]) So I understand why people are going away from XML. Stef On Fri, Dec 8, 2017 at 4:02 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 08.12.2017 um 14:21 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi monty >> >> >>> On Fri, Dec 8, 2017 at 9:03 AM, monty <monty2(a)programmer.net> wrote: >>> By "empty XML nodes," do you mean whitespace-only string nodes? >> >> Yes >> >>> Those are included because all in-element whitespace is assumed significant by the spec: https://www.w3.org/TR/xml/#sec-white-space >> >> I know. There was a discussion a while ago. I just lost a couple of >> hours understanding that :( >> >> But this is a super super super annoying practices. >> We had to test each nodes to see if it is a empty nodes so it makes >> everything a lot more complex without real justification >> beside the fact that these standardizers probably never implemented >> some real cases. >> This standard is a really out of reality from that perspective. > > Are you sure you do not oversimplify things? XML would be even more complex if these cases would be in the standard. It is not easy to decide if a whitespace is important or not. > Where do this whitespaces in your case come from? Most probably because the XML is pretty printed. That is inserting whitespaces into the serialized text. So why not just stopping to pretty print and your problem is gone. > > Norbert >> >>> The exception is if the element is declared in the DTD as only having element children ("element content"): https://www.w3.org/TR/xml/#dt-elemcontent >> >> Well the XML files that I had (I did not choose XML because I would >> have prefer JSON :) ), had no DTD :( >> >> So at the end of the day, this wonderful standard puts all the stress >> and burden to people. >> >>> >>> For example, if you declare an element like this: >>> >>> <!ELEMENT one (two,three*,four?)> >>> >>> Any whitespace around a "two," "three," or "four" element child of a "one" element is insignificant and ignored (unless #preservesIgnorableWhitespace: is true). Other parsers, like LibXML2 and Xerces, behave the same way. >>> >>> I'll see if I can come up with some easier way to deal with this, like an optional parser setting, new enumeration methods, or maybe a tree transformation. >> >> It would be A HUGE PLUS!!!!!!!!!!!!!!!!!! >> >> >> Because reality is that people have XML files with just nodes and no >> empty nodes and they are forced to >> Let me know because I could try. >> >> I was showing how to use Pharo to import code to pharo learners and >> this was a big drag. >> >> Stef >> >> >> I tried to set some values in the parser but it did not work. >> BTW I saw that the configuration logic forces to write the following >> >> | parser doc visitor | >> parser := XMLDOMParser new >> on: self xmlContents; >> preservesIgnorableWhitespace: true. >> >> and not >> >> | parser doc visitor | >> parser := XMLDOMParser new >> preservesIgnorableWhitespace: true. >> on: self xmlContents; >> >> >>> >>>> Sent: Tuesday, December 05, 2017 at 8:29 AM >>>> From: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>>> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>> Subject: [Pharo-dev] How to get rid of empty XML nodes? >>>> >>>> )Hi >>>> >>>> we are manipulating an XML document and I would like to get rid of the >>>> spurious empty string. >>>> We saw that the gt panes are doing it. >>>> >>>> (aNodeWithElements isStringNode >>>> and: [aNodeWithElements isEmpty >>>> or: [aNodeWithElements isWhitespace]] >>>> >>>> Is there a way not to produce empty nodes? >>>> Is there a simple way not to have to handle them >>>> >>>> Now each time we are dealing with a node with have to check. >>>> >>>> Stef >>>> >>>> >>> >

Dec. 10, 2017

Re: [Pharo-dev] Text Indentation in Pharo editor

by Stephane Ducasse

I think so too. Yesterday we got a crazy stuff spawning UI processes like hell. In fact I have the impression that a crazy progress is running from time to time. I wonder if it is not linked to tests. Stef On Sat, Dec 9, 2017 at 7:48 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 08.12.2017 um 21:24 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >> >> Hi Stef, >> >> Do you get the debugger issue even in a plain Pharo image? >> > I do > > Norbert >> Doru >> >> >>> On Dec 8, 2017, at 3:40 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> I would love to have Ctrl E and Ctrl A. >>> And yes we should not be different for the sake of it. >>> For the moment the reason is simple: we are full of work and even more. >>> >>> FYI: I'm starting at regular crash of the VM and regular superbad >>> behavior of the debugger (like hundred of debuggers, like spawing many >>> process) >>> there is a really bad problem there. >>> >>> Setf >>> >>>> On Fri, Dec 8, 2017 at 10:52 AM, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> >>>>> On 8 December 2017 at 11:37, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>>> >>>>> Torsten Bergmann wrote >>>>>> so we do it with different shortcuts than regular editors >>>>> >>>>> I wonder if it makes sense to allow the standard shortcut. The current one >>>>> is a bit like playing twister ;) >>>> >>>> >>>> We should be different if there is a good reason, >>>> but where possible (especially on UI interface) we should align with the >>>> majority. >>>> I feel this case is the latter. >>>> >>>> cheers -ben >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Don't give to get. Just give." >

Dec. 10, 2017

Re: [Pharo-dev] [Moose-dev] [ann] gtmondrian

by Stephane Ducasse

tx doru I will have to digest this. I will reread it multiple times. But I'm happy that the edges are not poluting BlElement :). Stef On Sat, Dec 9, 2017 at 9:25 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Here is an example that shows the distinction between edge and line: > > elementToVisualize := BlChicken chicken. > elementToVisualize forceLayout. > root := BlElement new constraintsDo: [:c | > c horizontal matchParent. c vertical matchParent]. > elementToVisualize allChildrenBreadthFirstDo: [ :each | > | label | > *label* := BlTextElement new > text: each gtDisplayString asRopedText; > background: Color white; > effect: (BlDropShadowEffect color: (Color gray alpha: 0.5) width: 10 > offset: 0@0). > label userData at: #model put: each. > root children > detect: [ :child | > (child userData at: #model ifAbsent: [ nil ]) = each parent ] > ifFound: [ :*parentLabel* | > | edge | > *edge := GtGraphEdge new from: parentLabel to: label.* > * parentLabel constraints graph addConnectedEdge: edge.* > * label constraints graph addConnectedEdge: edge* ]. > root addChild: label]. > root layout: (GtGraphHorizontalTreeLayout new layered; verticalGap: 20). > root > > With this we visualize the elements that make the chicken element demo: > - we create a label for each element > - we find the parentLabel corresponding to the parent element > - we create an edge between the parentLabel and the current label > > The example gives us this: > > > The edge is a constraint. It has no visual impact. And the graph layouts > take the edge constraints into account. The cool thing is the GtGraphEdge > is defined next to the graph layout classes, not in the core of Bloc. > > To add a visual impact, we have to create a separate line: > > > > > Thanks for the question. This email is now a comment in the graph layout > examples and can be viewed like this: > > > Cheers, > Doru > > > > On Dec 9, 2017, at 8:43 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > Super super cool. > > > On 9 Dec 2017, at 08:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are happy to announce GT Mondrian, a graph visualization engine built > on top of Bloc. > > It is similar to the original Mondrian and the Mondrian from Roassal, but > it is different in that it is built directly out of Bloc elements. This is > interesting because it allows us to combine typical widgets with > visualizations. The other interesting thing about it is that it validates > the design of Bloc: right now, the implementation has 509 lines of code > (excluding graph-specific layouts). The goal is to make visualization a > first class citizen and an integral part of the IDE. > > The key ingredient that made this happen is that Bloc can now treat graph > layouts, such as tree or force based, behave under the same rules as > typical widget layouts, such as grid or flow. The challenge comes from the > fact that a graph layout depends on the notion of edges between elements, > and we did not want to have elements know about edges in the core of Bloc. > > The solution was to split the typical edge implementation in graph > visualization libraries into two distinct concepts: > â¢ Line is an element that draws the connections. > â¢ Edge defines constraints imposed by connections between elements. > > > Can you give an example? > > BTW doru did you think about having a bloc layer on top of telescope model? > Because from that perspective telescope offers a visualisation model while > roassal/mondrian like design are > more a pen-oriented metaphor. > > I wanted to do it to learn Bloc but Iâm running against time and trying to > flush pilling duties (I want to also release > the book that we wrote with luc and olivier and convert the seaside book > and and andâ¦.. :( > > > > > Thus, edges form constraints, and constraints are what layouts deal with. > That is one reason why elements in bloc have the ability of defining > layout-specific constraints. Using this, we can nicely define edges between > elements as a plugin to Bloc, but still be able to connect arbitrary > elements. What's more, it turns out that we need constraints for other > layouts as well. For example, an element in a grid layout might specify the > span. > > The API of GT Mondrian is similar to the one from Roassal, but there are a > few differences as well. These are described in the Pillar documentation > available in the GitHub repo. > > The best way to experience GT Mondrian and its documentation is to load > the GToolkit as described here: > https://github.com/feenkcom/gtoolkit > > If you download the GT code through Iceberg, the documentation can be > experienced live by inspecting: > './pharo-local/iceberg/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar' > asFileReference > > > <mondrian-doc.png> > > > > > > Cheers, > The feenk team > > > -- > www.tudorgirba.com > www.feenk.com > > "Quality cannot be an afterthought." > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > <https://maps.google.com/?q=40,+avenue+Halley,%C2%A0+Parc+Scientifique+de+la…> > > Parc Scientifique de la Haute Borne > <https://maps.google.com/?q=40,+avenue+Halley,%C2%A0+Parc+Scientifique+de+la…>, > BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > -- > www.tudorgirba.com > www.feenk.com > > "Every successful trip needs a suitable vehicle." > > > > > >

Dec. 10, 2017

Re: [Pharo-dev] [Moose-dev] [ann] gtmondrian

by Tudor Girba

Hi, Here is an example that shows the distinction between edge and line: elementToVisualize := BlChicken chicken. elementToVisualize forceLayout. root := BlElement new constraintsDo: [:c | c horizontal matchParent. c vertical matchParent]. elementToVisualize allChildrenBreadthFirstDo: [ :each | | label | label := BlTextElement new text: each gtDisplayString asRopedText; background: Color white; effect: (BlDropShadowEffect color: (Color gray alpha: 0.5) width: 10 offset: 0@0). label userData at: #model put: each. root children detect: [ :child | (child userData at: #model ifAbsent: [ nil ]) = each parent ] ifFound: [ :parentLabel | | edge | edge := GtGraphEdge new from: parentLabel to: label. parentLabel constraints graph addConnectedEdge: edge. label constraints graph addConnectedEdge: edge ]. root addChild: label]. root layout: (GtGraphHorizontalTreeLayout new layered; verticalGap: 20). root With this we visualize the elements that make the chicken element demo: - we create a label for each element - we find the parentLabel corresponding to the parent element - we create an edge between the parentLabel and the current label The example gives us this: The edge is a constraint. It has no visual impact. And the graph layouts take the edge constraints into account. The cool thing is the GtGraphEdge is defined next to the graph layout classes, not in the core of Bloc. To add a visual impact, we have to create a separate line: Thanks for the question. This email is now a comment in the graph layout examples and can be viewed like this: Cheers, Doru > On Dec 9, 2017, at 8:43 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Super super cool. > > >> On 9 Dec 2017, at 08:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> We are happy to announce GT Mondrian, a graph visualization engine built on top of Bloc. >> >> It is similar to the original Mondrian and the Mondrian from Roassal, but it is different in that it is built directly out of Bloc elements. This is interesting because it allows us to combine typical widgets with visualizations. The other interesting thing about it is that it validates the design of Bloc: right now, the implementation has 509 lines of code (excluding graph-specific layouts). The goal is to make visualization a first class citizen and an integral part of the IDE. >> >> The key ingredient that made this happen is that Bloc can now treat graph layouts, such as tree or force based, behave under the same rules as typical widget layouts, such as grid or flow. The challenge comes from the fact that a graph layout depends on the notion of edges between elements, and we did not want to have elements know about edges in the core of Bloc. >> >> The solution was to split the typical edge implementation in graph visualization libraries into two distinct concepts: >> â¢ Line is an element that draws the connections. >> â¢ Edge defines constraints imposed by connections between elements. > > Can you give an example? > > BTW doru did you think about having a bloc layer on top of telescope model? > Because from that perspective telescope offers a visualisation model while roassal/mondrian like design are > more a pen-oriented metaphor. > > I wanted to do it to learn Bloc but Iâm running against time and trying to flush pilling duties (I want to also release > the book that we wrote with luc and olivier and convert the seaside book and and andâ¦.. :( > > > >> >> Thus, edges form constraints, and constraints are what layouts deal with. That is one reason why elements in bloc have the ability of defining layout-specific constraints. Using this, we can nicely define edges between elements as a plugin to Bloc, but still be able to connect arbitrary elements. What's more, it turns out that we need constraints for other layouts as well. For example, an element in a grid layout might specify the span. >> >> The API of GT Mondrian is similar to the one from Roassal, but there are a few differences as well. These are described in the Pillar documentation available in the GitHub repo. >> >> The best way to experience GT Mondrian and its documentation is to load the GToolkit as described here: >> https://github.com/feenkcom/gtoolkit >> >> If you download the GT code through Iceberg, the documentation can be experienced live by inspecting: >> './pharo-local/iceberg/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar' asFileReference >> >> >> <mondrian-doc.png> >> >> >> >> >> >> Cheers, >> The feenk team >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Quality cannot be an afterthought." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."

Dec. 9, 2017

Re: [Pharo-dev] Implementors of margins in GLMRubScrolledTextBrick

by Henrik-Nergaard

>>GLMRubScrolledTextBrick>>withoutMargins uses self margins: but I cannot find the method. This is because it is implemented in RubScrollTextMorph. GLMRubScrolledTextBrick implements #doesNotUnderstand: to send it to the rubric object. see: https://pharo.fogbugz.com/f/cases/17888/GLMRubScrolledTextBrick-relies-on-d… Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 9, 2017

Implementors of margins in GLMRubScrolledTextBrick

by Stephane Ducasse

Hi I'm working on 16969 https://pharo.fogbugz.com/f/cases/16969/ which is basically cleaning the use of rectangle instead of using Margin. Now I'm surprised because GLMRubScrolledTextBrick>>withoutMargins uses self margins: but I cannot find the method. Did I misses something? I rewrote it as withoutMargins self margins: (0@0) asMargin but I'm still curious. Stef

Dec. 9, 2017

Re: [Pharo-dev] Two tables that share the same data source!?

by Stephane Ducasse

Hi Elhamer where can we find the code of the improvements you did on FastTable? Stef On Tue, Aug 8, 2017 at 2:42 AM, Elhamer <abdelkhalekdev(a)gmail.com> wrote: > Hi Alex and thank you for your reply :)) > > Good to know that bloc already supports that, I am definitely moving to work > on/with it after that :)) > > I've never encounter that scenario on a a Pharo package too, but since i was > working on improving FTs, i thought why not!, besides, in apps with multiple > tables, it might be handy to define a single large data source and assign > columns to each table instead of defining a ds for each table, something > like that: > > ```` > |pane table1 table2 ds| > ds:=FTCellSampleDataSource new:10. > table1 := FTTableMorph new > extent: 500@500; > selectionMode: #column; > addColumn: (FTColumn id: 'column1'); > addColumn: (FTColumn id: 'column2'); > addColumn: (FTColumn id: 'column6'); > dataSource: ds; > selectRowIndex: 1; > showFirstRowSelection; > beMultipleSelection; > yourself. > table2 := FTTableMorph new > extent: 500@500; > selectionMode: #column; > addColumn: (FTColumn id: 'column3'); > addColumn: (FTColumn id: 'column4'); > addColumn: (FTColumn id: 'column5'); > dataSource: ds; > selectRowIndex: 1; > showFirstRowSelection; > beMultipleSelection; > layoutInset: 10; > yourself. > pane := Morph new. > pane layoutPolicy: TableLayout new. > pane listDirection: #leftToRight. > pane listCentering: #center. > pane wrapCentering: #center. > pane hResizing: #spaceFill. > pane layoutInset: 10@10. > pane cellInset:10@10. > pane color: Color red. > > pane addMorph: table1. > pane addMorph: table2. > pane openInWindow . > > ``` > <http://forum.world.st/file/n4959160/two_tables_single_ds.png> > > > > > -- > View this message in context: http://forum.world.st/Two-tables-that-share-the-same-data-source-tp4959153p… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Dec. 9, 2017