Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?
Hi Igor, Alex, we are actually using PhaROS underneath, which was built by the guys at Douai (Luc, Noury, et.al.). They deserve all the ROS interfacing credit :-) See http://car.mines-douai.fr/2014/06/how-to-install-pharos/ -- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On 24 Dec 2016, at 07:49, Alexandre Bergel wrote: > > Hi Igor, > > Johan Fabry and his group have been working on a complete environment on top > of ROS to steer robots. > https://pleiad.cl/research/software/lrp > > Cheers, > Alexandre > > >> On Dec 22, 2016, at 9:38 PM, Igor Stasenko wrote: >> >> Hi, >> >> i wonder, are there any projects to run/connect Pharo with ROS(robot >> operating system) >> i'm interested in any bits, starting from basic ones, >> since i'm gonna to work with it in closest future, so would be nice to use >> Pharo >> & stand on a shoulders of others, of course, to learn it fester and >> understand it better. >> >> -- >> Best regards, >> Igor Stasenko. > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >
Re: [Pharo-dev] REMINDER: TechTalk today, 16hs UTC. This are the links.
Small correction: 17:00 Europe time is 13:00 Santiago time. -- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On 13 Dec 2016, at 10:41, Esteban Lorenzano wrote: > > Hi, > > So… techtalk is today 16hs. That means: > > 17hs Europe > 16hs UK (and no, this is not a political joke :P) > 08hs San Francisco > 13hs Buenos Aires > 12hs Santiago (I think) > > … and I don’t know other timezones. > > The links we have for the meeting: > > youtube channel: > http://www.youtube.com/user/nicopasserini/live > > discord: > https://discord.gg/Sj2rhxn > > The idea is that we will try to give a live presentation and we can use the > discord channel to send questions that will be solved. > This is a little bit less participative than the other talks, but it was the > only way we found to stream video that everybody can see (and that it remain > for the future generations ;) ). > > cheers, > Esteban
Re: [Pharo-dev] [Pharo-users] [ANN] Pillar 4.0.0
Hi Doru,
it looks like there’s a problem with copySupport.mk, I had the same problem
with the Spec booklet. The file is using Linux only syntax for the cp command.
This was fixed for the Spec booklet after I raised an issue there, but it seems
the fix was not propagated everywhere it needs to be. Have a look at
https://github.com/SquareBracketAssociates/BuildingUIWithSpec/blob/master/copySupport.mk
and try to update your copySupport, it may fix your problem.
--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please
see http://emailcharter.org .
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of
Chile
> On Sep 14, 2016, at 18:40, Tudor Girba wrote:
>
> Hi,
>
> Ok, I found this document:
> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html
>
> And now I tried this:
>
> wget --no-check-certificate
> https://raw.githubusercontent.com/pillar-markup/pillar/master/download.sh
> chmod +x download.sh
> ./download.sh
> ./pillar archetype book
>
> and I got the book template. But, I do not know how to compile the book. I
> tried
>
> make
>
> or
> make book
>
> but I get:
>
> make
> mkdir -p ./book-result
> find . -type d -path ./book-result -prune -o -wholename "*/figures" -exec cp
> {} --parents -r ./book-result \;
> cp: ./Chapters/Chapter1/figures is a directory (not copied).
> cp: --parents: No such file or directory
> cp: -r: No such file or directory
> cp: ./figures is a directory (not copied).
> cp: --parents: No such file or directory
> cp: -r: No such file or directory
> cp: ./support/figures is a directory (not copied).
> cp: --parents: No such file or directory
> cp: -r: No such file or directory
> cp -r support/ ./book-result
> cp .latexmkrc ./book-result
> cp: .latexmkrc: No such file or directory
> make: *** [copySupport] Error 1
>
>
> I must be doing something wrong, but I do not know what. I am on a Mac 10.11
> and I am using bash. Could someone point me in the right direction?
>
> Cheers,
> Doru
>
>
>> On Sep 14, 2016, at 10:49 PM, Tudor Girba wrote:
>>
>> Hi,
>>
>> Where can I find the new template system for Pillar?
>>
>> Cheers,
>> Doru
>>
>>
>>> On Jul 22, 2016, at 3:41 PM, Thibault ARLOING
>>> wrote:
>>>
>>> Hello,
>>>
>>> I'm happy to announce the latest release of Pillar.
>>> This release has been possible because of the hard work of Damien Cassou,
>>> Cyril Ferlicot, Yann Dubois, Thibault Arloing and Lukas Komarek.
>>> What did it bring and what are the largest changes ?
>>>
>>> • Huge cleaning of code and Dependencies
>>> • Many bug fixes
>>> • Huge refactoring of internal parts
>>> • Extract phase management into an external project
>>> (LightPhaser)
>>> • Transformers and Phases are all Pipes
>>> Remove Compilation cycle
>>> • Remove template handling from Pillar
>>> • Remove generation of pillarpostExport.sh
>>> • Pillar now exports files to JSON format
>>> • Command for pillar archetypes "./pillar archetype book", book can be
>>> replaced by other archetype names (see Pillar documentation)
>>> • Possibility to load an archetype with a Makefile to compile pillar
>>> files
>>> Features
>>> • Check phase to check syntax
>>> • EPub exporter for e-books (use pillar archetypes for this)
>>> • Semantic links to Youtube and Wikipedia
>>> • Citations for LaTeX
>>> • Structures (see Pillar documentation)
>>> • Footnotes for HTML, Markdown, LaTeX and AsciiDoc
>>> • Improvement of parsing configuration failure message
>>> Major changes
>>> • Metadata field in configuration to separate data from configuration
>>> properties
>>> • Support files in configuration does no longer exists
>>> • "disableTransformers" property is now named "disabledPhases"
>>> • AsciiDoc file extension is now ".asciidoc"
>>> • Pillar now manages one input file, not a collection of input files
>>> anymore
>>> • Parameter inputFiles is now replaced by inputFile
>>> The documentation of Pillar will be update as soon as possible to fit those
>>> changes.
>>>
>>> Cheers,
>>>
>>> Thibault
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Sometimes the best solution is not the best solution."
>>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "It's not how it is, it is how we see it."
>
>
>
Re: [Pharo-dev] [Moose-dev] Ask HN: Examples of elegant, non-trivial Smalltalk? | Hacker News
I was at that talk, and I am not convinced that we are at that level, we are certainly not better in my opinion. The advantage that they have is the domain-specific language on top of the parsing infrastructure which makes it easy and fast to write (at least) the demos he is showing. We don’t have that and his talk showed me that it is an important thing that is missing. -- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Jul 29, 2016, at 08:38, Serge Stinckwich > wrote: > > When I see all the buzz around languages workbenches like Rascal: > https://www.youtube.com/watch?v=Ffx7VtEOSx4 > > with MOOSE+RB+SmaCC+Reflectivity+GTools we are close to these tools > (or even better).
Re: [Pharo-dev] [Pharo-users] [ANN] file dialog replacement experiment
This is excellent !!! We should change the default file browser to be this one ! -- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Jul 16, 2016, at 13:05, Peter Uhnák wrote: > > Couple more updates: > > > If you truncate, you could put the full, non truncated path in a pop over, > > that would be a cheap way to solve that problem, no ? In any case, in my > > testing there was enough space. > > Fixed > > > Maybe also add a trailing / to indicate that it represents the directory > > and not the selection ? > > Fixed > > > the path is initially blank, it only fills when I start clicking. > > Fixed > > > And related to github filetree, what is the proper way to get a new version > > once you loaded the code ? > > What seems to work is to delete github-cache folder in image directory and > unload both file-dialog and BaselineOfFileDialog packages, and then reexecute > the load script again. > As this is really stupid, I'll have to ask Thierry or someone. > > And couple of more fixes based on Torsten's feedback: > > 1. the Open/Cancel buttons are swapped on Windows > 2. the FileSystem bookmark has been replaced with available disks on Windows > (C:, D:, ...) > 3. Added basic entry completion when saving; note that Dark Theme and the > EntryCompletion popup do not like each other --- this has to be fixed inside > Pharo. > > > > > One more thing I want to add really soon: clicking on a file would open a > GTInspector on the side (as part of the window), so you can see the preview > of text/image/etc > > Peter > > On Sat, Jul 16, 2016 at 2:25 PM, Peter Uhnák <mailto:i.uh...@gmail.com>> wrote: > > > On Fri, Jul 15, 2016 at 2:00 PM, Sven Van Caekenberghe <mailto:s...@stfx.eu>> wrote: > >> On 14 Jul 2016, at 23:49, Peter Uhnák > <mailto:i.uh...@gmail.com>> wrote: >> >> Hi Sven, >> >> What I am missing in the UI is some indication of the path that leads to the >> current selected file. Right now, I am wondering where exactly I am, I feel >> a bit lost (this is of course from the technical standpoint of a path in a >> tree). This could be done with a popup, a trail, a pop-over. >> >> I've added this couple of days ago (as I was missing this too), I just >> forgot to push the update to github (one downside compared to smalltalkhub >> :)). >> >> The only problem is that the image directory name is usually really long >> (the longest I have is 110 characters as it includes the build's name), so >> it doesn't exactly fit in. >> There is some shortening happening based on the window's width but it's not >> perfect. > > I had another look. Yes, this is cool. > > If you truncate, you could put the full, non truncated path in a pop over, > that would be a cheap way to solve that problem, no ? In any case, in my > testing there was enough space. > > If Spec supports it, then it should be easy. > > > Maybe also add a trailing / to indicate that it represents the directory and > not the selection ? > > Originally I wanted to make it bold, but again, Spec doesn't support Text > properly; trailing slash might be a compromise for now > > > > > Also when I tested it, using > > FDOpenFileDialog new openModal. > > the path is initially blank, it only fills when I start clicking. > > That's a bug, I'll fix that. > > > BTW, could it be that FDMorphicUIManager becomes default automatically ? > > That seems quite aggressive, I don't feel it's stable enough… I could add > something like #load, and #loadDefault to the load script… but then you might > as well execute the beDefault. I'm not sure yet. > > > And related to github filetree, what is the proper way to get a new version > once you loaded the code ? > > I don't know, but it should be the same as with any other (e.g. smalltalkhub) > project, since it's both monticello, no? I've never done this, so I don't > know. (Usually when I am updating I look at the individual commits because I > want to know what has changed.) > > Peter >
Re: [Pharo-dev] [Pharo-users] remove unused variables
This was changed somewhere in November by Marcus and Miguel, and it was intentional, as part of the work on annotations on the AST that enabled breakpoints. (Breakpoints use the same highlighting mechanism). > On Apr 21, 2016, at 18:52, Peter Uhnák wrote: > > The editor used to inform when there was an unused local variable and offered > to remove it. > > Is it possible to get this behavior back, or is it a feature regression with > the "new" (this changed some time ago) editor? > > Thanks, > Peter ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Moose-dev] [Pharo-users] RTAnchorConstraint
> On Mar 10, 2016, at 12:08, Alexandre Bergel wrote: > >> >> There is no other solution? Alex, do you have any idea? > > To which problem? Copy-paste from original mail: anchor constraints: they do not play well with layouts and animations. Try the code below (adapted from the example to use the layout and animation of LRP ) and you will see that the circles keep spinning around, they never stop. I think it would be better for them to stop ;-) | v lbls es e1 e2 a1 a2 layout stepping| v := RTView new. lbls := RTLabel new elementsOn: #(#First #Second). es := RTEllipse new size: 30; borderColor: Color black; elementsOn: #(#source #dest). v addAll: lbls; addAll: es. es @ RTDraggable. es @ RTLabeled. e1 := RTArrowedLine new withContinuousCircleAttachPoint; color: Color black; edgeFrom: es first to: es second. v add: e1. e2 := RTArrowedLine new withContinuousCircleAttachPoint; color: Color black; edgeFrom: es second to: es first. v add: e2. a1 := RTAnchorConstraint new. a1 anchorShape size: 10. a1 guideLine color: Color red. a1 element: lbls first; edge: e1; balance: 0.2; minDistance: 10; build. (a2 := RTAnchorConstraint new) element: lbls second; edge: e2; balance: 0.2; minDistance: 10; build. layout := RTForceBasedLayout new charge: -450; length: 100; doNotUseProgressBar; applyOn: es; yourself. layout initialLayout: RTSugiyamaLayout new. stepping := RTSpringLayoutStepping new view: v; layout: layout; afterBlock: [ v canvas camera focusOnCenter]. v addAnimation: stepping. ^ v ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Moose-dev] [Pharo-users] RTAnchorConstraint
> On Mar 9, 2016, at 18:51, Peter Uhnák wrote: > > > > On Wed, Mar 9, 2016 at 10:02 PM, Johan Fabry <mailto:jfa...@dcc.uchile.cl>> wrote: > Heh, also a funny feature of your anchor constraints: they do not play well > with layouts and animations. Try the code below (adapted from the example to > use the layout and animation of LRP ) and you will see that the circles keep > spinning around, they never stop. I think it would be better for them to stop > ;-) > > can't help myself :) > > https://youtu.be/PGNiXGX2nLU?t=1m <https://youtu.be/PGNiXGX2nLU?t=1m> Hehe, good one :-) https://youtu.be/uo0o8eQWfcI ! :-P > > stepping := RTSpringLayoutStepping new > view: v; layout: layout; > afterBlock: [ v canvas camera > focusOnCenter]. > > The problem is that RTSpringLayoutStepping>>view sets in effect the layout on > all elements in the view, which obviously won't work since they'll start > competing. > > I'm not sure right now how to address it, but try this > > stepping := RTSpringLayoutStepping new > view: RTView new; layout: > layout; > nodes: es; > afterBlock: [ v canvas camera > focusOnCenter]. Sorry, I don’t know enough of the internals to understand what’s going on. The solution is not a solution for me, because it effectively removes the animation, we only see the the resulting layout. There is no other solution? Alex, do you have any idea? > Ah right, thanks. I've extracted the class from my code and I have different > removal mechanism... > Please try the latest version, it should be fixed there. Fixed, thanks! But now there is a new bug RTAnchorConstraint>>computeExtraDistance that I cannot reliably reproduce, I only have a stack trace, sorry: Array(Object)>>errorSubscriptBounds: Array(Object)>>at: Array(SequenceableCollection)>>first Array(SequenceableCollection)>>anyOne Array(Collection)>>max RTAnchorConstraint>>computeExtraDistance [ :crossings | element translateBy: aSegment vector normal * (minDistance + self computeExtraDistance) negated ] in RTAnchorConstraint>>moveAwayFromSegment: BlockClosure>>cull: Set(Collection)>>ifNotEmpty: RTAnchorConstraint>>moveAwayFromSegment: RTAnchorConstraint>>moveElement RTAnchorConstraint>>update [ self update ] in RTAnchorConstraint>>build BlockClosure>>cull: BlockClosure>>cull:cull: TRTranslationCallback>>shape:step: [ :c | c isTranslationCallback ifTrue: [ c shape: self step: aStep ] ] in TREllipseShape(TRCallableObject)>>triggerCallbacksForStep: OrderedCollection>>do: TREllipseShape(TRCallableObject)>>triggerCallbacksForStep: TREllipseShape(TRAbstractBoxShape)>>fromRectangle: TREllipseShape(TRAbstractBoxShape)>>fromRectangle:color: RTEllipse>>updateFor:trachelShape: RTEllipse(RTShape)>>updateFor: RTElement(RTShapedObject)>>update ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Moose-dev] Re: [Pharo-users] Re: Call for action for Roassal
Heh, also a funny feature of your anchor constraints: they do not play well with layouts and animations. Try the code below (adapted from the example to use the layout and animation of LRP ) and you will see that the circles keep spinning around, they never stop. I think it would be better for them to stop ;-) | v lbls es e1 e2 a1 a2 layout stepping| v := RTView new. lbls := RTLabel new elementsOn: #(#First #Second). es := RTEllipse new size: 30; borderColor: Color black; elementsOn: #(#source #dest). v addAll: lbls; addAll: es. es @ RTDraggable. es @ RTLabeled. e1 := RTArrowedLine new withContinuousCircleAttachPoint; color: Color black; edgeFrom: es first to: es second. v add: e1. e2 := RTArrowedLine new withContinuousCircleAttachPoint; color: Color black; edgeFrom: es second to: es first. v add: e2. a1 := RTAnchorConstraint new. a1 anchorShape size: 10. a1 guideLine color: Color red. a1 element: lbls first; edge: e1; balance: 0.2; minDistance: 10; build. (a2 := RTAnchorConstraint new) element: lbls second; edge: e2; balance: 0.2; minDistance: 10; build. layout := RTForceBasedLayout new charge: -450; length: 100; doNotUseProgressBar; applyOn: es; yourself. layout initialLayout: RTSugiyamaLayout new. stepping := RTSpringLayoutStepping new view: v; layout: layout; afterBlock: [ v canvas camera focusOnCenter]. v addAnimation: stepping. ^ v > On Mar 9, 2016, at 17:56, Johan Fabry wrote: > > >> On Mar 7, 2016, at 11:34, Peter Uhnák > <mailto:i.uh...@gmail.com>> wrote: >> >> I've just commited RTAnchorConstraint to latest Roassal, see class-side >> example there. >> > I have been trying it, and there is a first version that works now, thanks! > > I even have a bug report for you … before, when I removed the edge, the label > was also removed automatically. Now this is no longer the case. :-( > > ---> Save our in-boxes! http://emailcharter.org <http://emailcharter.org/> > <--- > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/~jfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of > Chile > > ___ > Moose-dev mailing list > moose-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Call for action for Roassal
> On Mar 7, 2016, at 11:34, Peter Uhnák wrote: > > I've just commited RTAnchorConstraint to latest Roassal, see class-side > example there. > I have been trying it, and there is a first version that works now, thanks! I even have a bug report for you … before, when I removed the edge, the label was also removed automatically. Now this is no longer the case. :-( ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Call for action for Roassal
Excellent, thanks a lot! I will take a look at that tomorrow. > On Mar 7, 2016, at 11:34, Peter Uhnák wrote: > > Hi Johan, > > I've just commited RTAnchorConstraint to latest Roassal, see class-side > example there. > > I've been using it for my class diagrams where it works quite well, however > class diagrams are usually orthogonal-ish, which makes it a bit nicer. > > > The Anchor will avoid intersecting it's own line, and one of the end shapes > (it should both but apparently I have a bug there...). > It doesn't look at other lines, however you can specify on which side it > should be. > > (You can also put the node label inside the circle with `el @ (RTLabelled > new center)` but you probably know that.) > > > I have also a global edge labeling layout which produces good placement… but > it's slow as hell… I need to write a fast flow alogrithm… > > Also the Anchor currently doesn't work with self-edges. On the other hand > Roassal doesn't have self-edges yet so it shouldn't be a problem. :) > > Peter > > > On Mon, Mar 7, 2016 at 2:34 PM, Johan Fabry <mailto:jfa...@dcc.uchile.cl>> wrote: > > Better late than never :-) (working on the holidays backlog) > > I only have one request: better positioning on labels of nodes and edges. For > example see the image: three of the four labels are badly positioned because > the bounding box of their text is intersected by one or more edges. > > > I know that to solve this generally is hard, but for simple cases like this > it should be possible. > > Ah, and it should work well with animations and dragging of course ;-) > >> On Feb 24, 2016, at 05:51, Alexandre Bergel > <mailto:alexandre.ber...@me.com>> wrote: >> >> Dear community, >> >> As you may have seen, Roassal has entered a stabilization phase. The book >> AgileVisualization.com <http://agilevisualization.com/> will soon be >> released. After its release, Roassal will go over a new development phase. >> In order to prepare it, I am asking this question: >> >> What are the 3 aspects you would like to see improved in Roassal? >> >> You can answer publicly or by sending private messages. >> >> Kind regards, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> ___ >> Moose-dev mailing list >> moose-...@list.inf.unibe.ch <mailto:moose-...@list.inf.unibe.ch> >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> <https://www.list.inf.unibe.ch/listinfo/moose-dev> >> > > > > ---> Save our in-boxes! http://emailcharter.org <http://emailcharter.org/> > <--- > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/~jfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of > Chile > > > ___ > Moose-dev mailing list > moose-...@list.inf.unibe.ch <mailto:moose-...@list.inf.unibe.ch> > https://www.list.inf.unibe.ch/listinfo/moose-dev > <https://www.list.inf.unibe.ch/listinfo/moose-dev> > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Moose-dev] Call for action for Roassal
Better late than never :-) (working on the holidays backlog) I only have one request: better positioning on labels of nodes and edges. For example see the image: three of the four labels are badly positioned because the bounding box of their text is intersected by one or more edges. I know that to solve this generally is hard, but for simple cases like this it should be possible. Ah, and it should work well with animations and dragging of course ;-) > On Feb 24, 2016, at 05:51, Alexandre Bergel wrote: > > Dear community, > > As you may have seen, Roassal has entered a stabilization phase. The book > AgileVisualization.com will soon be released. After its release, Roassal will > go over a new development phase. In order to prepare it, I am asking this > question: > > What are the 3 aspects you would like to see improved in Roassal? > > You can answer publicly or by sending private messages. > > Kind regards, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > ___ > Moose-dev mailing list > moose-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Moose-dev] roassal2 seems to work well now
If Esteban says there are problems, there are problems. (And he did say so.) > On Jan 17, 2016, at 22:43, Alexandre Bergel wrote: > > Johan? > > Does the image still crash? > > Alexandre > > >> On Jan 17, 2016, at 2:02 PM, Tudor Girba wrote: >> >> Hi, >> >> With the latest development, Roassal2 seems to work well. >> >> For example, the rendering of the logical view of Glamour browsers was >> broken, and now it works well. This is great news. >> >> >> >> Is this just my impression? Do we know if there are still open issues with >> the FFI in this area? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every thing should have the right to be different." >> >> >> >> >> ___ >> Moose-dev mailing list >> moose-...@list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > ___ > Moose-dev mailing list > moose-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] [ANN] OSSubprocess first milestone
That looks very cool to me, it would have come quite in handy for some project that I did last year ;-) > On Jan 15, 2016, at 13:13, Mariano Martinez Peck > wrote: > > Luc, Damien, et all. > > I implemented the kind of API Luc suggested, which was a great idea. I took > also his API to answer Damien question of could we do a "tail -f" example. So > I made a little example where I run "tail -f system.log" and I keep a > Playground updated with the stdout :) > Here is the video: > > https://dl.dropboxusercontent.com/u/6980943/tailExample.mov > <https://dl.dropboxusercontent.com/u/6980943/tailExample.mov> > > Let me know what do you think. > > Cheers, > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0
It looks much better to me, yes. I would need to use it some time before I could give more detailed feedback. (And I can’t really do that until the FFI is fixed, because all my development crashes the VM since I am using Roassal. So I am still on the last Pharo version before the VM switch.) One last thing is that I am not convinced on having the ‘proceed’, ‘step into’, ‘step over’ et cetera buttons on the stack pane. To me they are more related to the source code pane, as you always see the results of pressing those buttons there, but on the stack not always, e.g. the ‘step over’ actions. > On Jan 9, 2016, at 19:06, Tudor Girba wrote: > > Thanks. What do you think of the new solution? Is it sufficient? > > Doru > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0
I second Torsten’s comment with regard to the use of space, I also think the original positioning of stack and code panes is more efficient. > On Jan 8, 2016, at 14:28, Torsten Bergmann wrote: > > Hi, > > with a moldable debugger we should (in the future) be able to support > debugging also different/other programming languages/DSLs in Pharo :) > - although usually one does necessary have such a use case. So I guess > GTInspector or other will be adopted to own needs more than GTDebugger. > > However: > The only objection so far is that I dislike the order/size of the panes. > The placement of the panes in GTDebugger (as for instance found in Moose) > requires often to use the scrollbars of the pane showing the stack because > of the text length. > > In GTDebugger the stack is at the top left, the source at the top right with > a common splitter beneath the two panes: therefore the height (depth) of the > stack pane is always the height of the code pane. > When you have a long method to debug on the right much space is wasted for > a deep stack on the left although you might only be interested in a few top > frames. > > Contrary when you have are interested in a deep/full stack and you increase > the > height of the stack pane on the left you directly increase the height of the > code > pane and for short methods you waste a lot of space in the source pane as > well. > > This is much better solved with the positioning in the traditinal Debugger: > - Stack > - Source > - other > > So in my opinion We should preserve: > > - TOP:the stack at the top (using the full width of the window, so only > vertical scrolling >has to be done to "roll" on the stack, no need for horizontal > scrolling as the area >is wide enough) > - MIDDLE: the source code pane in the middle (also using the full width of > the window and there >fore in alignment with code pane in the the usual tools like > Nautilus, change sorter, ...) > - BOTTON: one or more panel for inspection at the bottom > > It would be OK for me if others like the new layout better - but at least > there should be an > option to support the traditional layout as well (or support pane > movemen/docking as in other IDEs) > > Also the debugger window in Moose wastes a lot of space/has unused space > within the > windows client are itself. For instance the splitters are very thick which > might be an issue of > the moose theme. > > Thanks > T. > > Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr > Von: "Tudor Girba" > An: "Pharo Development List" , "Moose-dev Moose > Dev" , "Any question about pharo is welcome" > > Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 > > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: the > GTDebugger. As this is a significant change that might affect your workflow, > here is some background information to help you deal with the change. > > First, you should know that the change is not irreversible and it is easily > possible to disabled the new debugger through a setting. However, please do > take the time to provide us feedback if something does not work out for you. > We want to know what can be improved and we try to react as fast as we can. > > A practical change comes from the fact that the variables are manipulated > through a GTInspector, which makes it cheaper to maintain in the longer run. > > > While the first thing that will capture the attention is the default generic > interface, the real power comes from the moldable nature of the debugger. > Like all other GT tools, GTDebugger is also moldable by design. This means > that we can construct custom debuggers for specific libraries at small costs > (often measured in a couple of hundred lines of code). > > > > Here is an introductory overview blog post that also includes some links for > further reading: > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com[http://www.tudorgirba.com] > www.feenk.com[http://www.feenk.com] > > "Beauty is where we see it." ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] do you know we have an issue tracker? (rant)
Just to be sure, did you get notified for this one? https://pharo.fogbugz.com/f/cases/17309/Roassal2-in-Pharo-5-produces-a-segfault > On Jan 4, 2016, at 11:34, Esteban Lorenzano wrote: > > Hi guys, > > So… last two weeks I was first in Togo with Stef and after taking holidays > for the end of the year. > During that time some bugs on new FFI emerged and were talked in this list… > > Today I came back to work and I wanted to walk through the issues to priorize > and start work on fixing them… and no reports on the issue tracker :( > > So I’m forced to do email-archeology to dig up the problems… or just ignore > them until a report arrives. > > What is not in the issue tracker does not exist: PLEASE REPORT YOUR ISSUES. > > thanks, > Esteban > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Moose-dev] Roassal2 in Pharo 5 -> segfault
> On Dec 30, 2015, at 07:51, Esteban Lorenzano wrote: > > Hi, > > I’ve seen this around… I think is because a problem copying memory… I will > check it (next week, I’m on holidays now) but I would like to have a bug > report, please. Done! https://pharo.fogbugz.com/f/cases/17309/Roassal2-in-Pharo-5-produces-a-segfault Are you In Argentina for new year? Feliz año nuevo and enjoy the asado! :-) > btw… the crashes are not related to Spur but the new FFI implementation (and > the migration from old NativeBoost). Spur itself is pretty stable :) Great! Now just to get the FFI to be as stable as Spur ;-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
[Pharo-dev] Roassal2 in Pharo 5 -> segfault
Hi all, just in case this is not a known bug: Intensive use of Roassal2 in Pharo 5 causes a segfault of the mac vm. A crash.dump is attached. It’s the vm I got just now ( wget --quiet -O - get.pharo.org/50+vm | bash ) and Pharo5 with Alexes’ 17280 slice to make Roassal visualize shapes correctly. To reproduce, all I need to do is have a visualization open with a layout animation and after some time it will crash. I use this in LRP and I can give easy steps to reproduce if needed. crash.dmp Description: Binary data ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] Transcendental #new (was Re: why Pillar)
Robert, by talking about ‘a knee-jerk reaction’ and ‘a lack of knowledge’ you are being rude to us. Please don’t do that. In our mails we have been courteous and avoided using such hurtful expressions. Also, there is a difference between lack of knowledge and lack of time. I am only human with limited time and matters which are more pressing than the discussion you insist on holding. Consider it from my point of view: I am not forcing you to think about design decisions of the JIT of the domain-specific language for robotics that am I building. Greetings, > On Dec 28, 2015, at 08:29, Robert Withers wrote: > > Which is exactly what I did, I posted how it is related and still caught a > knee-jerk reaction. I am drawing a line. I will continue to reference > religious and scriptural meta-models. There is coherent thought in these > models and they are familiar to the majority of the people on the planet, the > average person, even if the intellectuals fail to resonate with it. This > familiarity makes it a good model for the average person to interact. Seems > to be a lack of knowledge on the side of the intellectuals. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] Transcendental #new (was Re: why Pillar)
> On Dec 27, 2015, at 15:18, Robert Withers wrote: > > Wait a second here. Let's be clear. In your first paragraph you say no need > to feel that I am censored or ostracized, then the second paragraph you > censor me. You did not completely take into account my sentence. The second part says: "for your spiritual and/or religious point of view”. > Alright, I ask you all. Which meta-model is acceptable for practical work in > my stack? I need a meta-model to describe it, or rahter anyone should be able > to skin the meta-model they want and that makes most sense. These > consciousness meta-models, or meta-memes, from religious tradition are > well-defined models. I have no opinion on this, this is a design question for your work, and not straightforwardly related to Pharo itself. In my opinion and apparently in the opinion of others as well, this is not a topic for this mailing list. Sending multiple mails to the list about it can be considered bad netiquette. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] [IMPORTANT] Starting migration to Spur VM
Sorry for the stupid question, but how should I adapt my CI job? I saw that the last build failed with no tests being run, so I guess this was due to the VM being changed. > On Dec 14, 2015, at 07:24, Esteban Lorenzano wrote: > > 5) You will need to adapt your Pharo 5.0 related apps and CI processes (to > take care about new VM). ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] [IMPORTANT] Starting migration to Spur VM
Excellent work, thanks a lot !! > On Dec 14, 2015, at 07:24, Esteban Lorenzano wrote: > > We will start migration to Spur today. > To complete it, we will require some time, specially to adapt the CI and > check everything is ok. > > Spur will allow us to do a big step forward in Pharo development, in the > concrete you will see it immediately for this: > - We have noticed a speed increment of 100% in tiny benchmarks (and according > to Eliot, it will be at least 35% in general on the system). > - No more GC stops (noticeable when running large systems) > - We will be able to scale our systems up to 2G memory consumption without > loosing performance. > > But, this will have some drawbacks in the first times: > > 1) VM will not be compatible between versions anymore: Pharo 5.0 will have a > Pharo Spur VM associated (and they are not compatible). > - There WILL NOT be a "non-spur" version of Pharo 5.0. Once completed > the transitions, this will be the only one. > > 2) NativeBoost-FFI implementation has been replaced with a new implementation > who relies in ThreadedFFIPlugin and IA32Plugin. While we worked a lot to do > this transition as painless as possible and we achieve a good level of > backward compatibility (most uses of #nbCall: should work out of the box), > there are some problems we cannot solve: > - there are some stuff not possible to compatibilise, notably: > - Structures now need to inherit from FFIExternalStructure > - Arrays now are now shadowed > - in general is a bit slower (impossible to compete with ASM) but in > general is not perceptible. > - THERE WILL BE BUGS AND NON-IMPLEMENTED FEATURES: Current > implementation is validated with Athens and even Roassal was working, but of > course that does not covers all cases. > 2.1) ASMJIT will be removed from system and put in a separated packages. > NOTE: There will be a blog post explaining FFI-NB architecture during the > week. > > 3) There are more or less 70 new failing tests, some of them important than > we need to fix as soon as possible. Please, please, please, help us with them > :) > > 4) In general we foresee the system will became unstable some weeks, before > it gets back to normal. Please be patient. > > 5) You will need to adapt your Pharo 5.0 related apps and CI processes (to > take care about new VM). Some programs will stop work at all (for example, I > think Pharo-launcher will need to be adapted). > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo5] Semantic Warnings as icons in the editor
> On Nov 29, 2015, at 10:21, Thierry Goubier wrote: > > Le 29/11/2015 14:14, Nicolas Cellier a écrit : >> It's nice, but I like the Compiler to be pedantic in such cases and >> manifest itself BEFORE accepting the method. >> One thing is suspicious patterns, another is obviously wrong code. Can't >> we have graduated responses? > > The problem is that certain semantic warnings were false positives, as the > recursive block definition. > > A := [ ... A value ]. Indeed, this warning happens to me from time to time (I tend to use blocks as lambdas in some cases) and it is *extremely* annoying to have to close the warning window every time. I think I will address that tomorrow … ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo5] Semantic Warnings as icons in the editor
And now the question for the monday morning development effort is: what more semantic warnings of the compiler can we reveal like this? :-) > On Nov 28, 2015, at 19:06, Cyril Ferlicot wrote: > > This is really cool ! :) > One more step to get a nice IDE! > Thank you for your efforts :) > > On Saturday, November 28, 2015, Marcus Denker <mailto:marcus.den...@inria.fr>> wrote: > Hi, > > One result of Friday’s Pharo Sprint in Chile: Use the nice icons of the new > text editor > to display some of the semantic errors nicely (instead of breaking flow with > a intrusive dialog): > > This was done by Johan based on the prototype Miguel did in September: > > 1) unused temps: > > > > (the “drag the crosshair”r is an artefact of the snapshot tool) > > 2) temps used that are not initialised: > > > > > In a next step, we need to integrate that with the QA tool… no need to have > this reported > twice. > > What is nice is that this simplified the Compiler: instead of having an > Exception and raising > it, we now just annotate the AST: > > unusedVariable: variableNode > > variableNode propertyAt: #semanticWarning put: 'unused variable’ > > (this is very simple for now, with a node just being able to have one kind of > semanticWarning). > > SemanticWarningIconStyler is what adds the icon. It has 4 methods with one > line each. > > Marcus > > > > -- > Cheers > Cyril Ferlicot > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] Spec LabelModel's #font: and other styles
I think it is better to avoid setting absolute style info for labels, e.g. font size and color. This because system settings allow you to set, e.g. font size systemwide, and it would be ugly if suddenly some labels don’t obey. Now, what could be done is to set some attributes like ‘bigger’, ‘smaller’, et cetera, and these should then take the system settings into account. > On Oct 2, 2015, at 08:47, Peter Uhnák wrote: > > Does it make sense to be able to specify font and similar at Spec-level? > > And not just font, also the size, color, or emphasis (which currently only > emphasis is supported). > > From one perspective it's handy, because I can change it at a whim, however I > wonder whether this shouldn't be responsibility of some styler instead. > > Text as far as I know is capable of storing styled information. This would > enable to outsource the style information to someone else (e.g. your > stylesheet). However from practical perspective for the end user it would be > extra work as it would add an indirection step. > > For TextModel that would be clearly better (because you might want to style > different parts of text differently), however for LabelModel I'm not so sure. > > Any opinions? > > Thanks, > Peter ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Moose-dev] [Pharo-users] Pillar 0.56 : New features, new syntax
Aah silly me, I still had the old version of Pillar. Many apologies! Now it works, but I found a bug: do a find for ‘shown in Section 5.3.3’ in the same html file. The section title there is V.3.C. So it should say ‘shown in Section V.3.C.’, right? > On May 24, 2015, at 22:17, Cyril Ferlicot wrote: > > Hi, > 2 possibility: > - You have an old version of Pillar > - You check the wrong file. > > With the version 0.47 of Pillar we changed the way files was generated. > Before if you had a file foo.pillar exported foo.pillar.html > but since the version 0.47 you get foo.html only. > > So check if you have a file "Fuel.html" and if you don't have it just > execute ./download.sh before the ./compile.sh > > You should get that : > https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/Fuel/Fuel.html > > :) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] Pillar 0.56 : New features, new syntax
Cyril, thanks for doing all of this, but now the links seem to be broken, at least for the html export on my machine. :-( I am working on the Fuel chapter, and I see that inter-file links are broken in the first paragraph, and intra-file links are broken e.g. figure 6.1. Example of changes to a class. Could you have a look? The pillar file is in github, the Fuel.pillar.html result of ./compile.sh is here: https://dl.dropboxusercontent.com/u/31426460/Fuel.pillar.html Thanks in advance! > On May 22, 2015, at 18:12, Cyril Ferlicot wrote: > > I already changed the links on Enterprise Pharo (you can find a table > with the list of the inter-files links on the README.md) > > On last thing for the people who write book for SquareBracketAssociates: > It would be good to have some conventions, so if you create anchors > use this form : > @sec:nameOfSection for a section > @cha:nameOfTheChapter for a title of chapter > @fig:nameOfFigure for a figure > @spt:nameOfTheScript for a script ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] QualityAssistant v0.4
Some weird behavior in quality assistant. Have a look at this method: duplicateVar: aVarName self show: 'Var: ', aVarName, ' redefinition ignored'. This raises the issue: ‘Use cascaded nextPutAll:’s instead of #, in nextPutAll:’ It also pops up the automatic rewrite icon, so I clicked on it to see how it would transform the code. Result: duplicateVar: aVarName self show: 'Var: ' , aVarName; show: ' redefinition ignored' Needless to say, that’s not a behavior preserving transformation. > On Apr 22, 2015, at 03:58, Yuriy Tymchuk wrote: > > Please give me a feedback about your experience, as I want to make it even > more useful. Either write me an email, or open an entry at: > https://github.com/Uko/QualityAssistant/issues > <https://github.com/Uko/QualityAssistant/issues> ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4
Hola, It looks like a really cool tool! I just added it to my LRP development image and I plan on using it full time. I am always interested in writing cleaner code. So expect comments from me :-) Actually I already have one: For one class I got the critic ‘References an abstract class’ and 'Subclass responsibility not defined’. Excellent that you found it, but now I have to go through all the methods of the class to see where the first critic comes from, and through all methods of all leaf classes for the second one. :-( :-( :-( That’s a lot of work for me to rescue some information which apparently the tool already knows. Please add more information on where the issue is on these kinds of errors, so I can fix them more easily ... Thanks and keep up the good work! > On Apr 22, 2015, at 03:58, Yuriy Tymchuk wrote: > > Hi everyone! > > Probably most of you know, that I am developing a tool called > QualityAssistant, which displays current critics about your code in > SystemBrowser, Inspector and Spotter. > > I’m happy to tell you that there is a new release v0.4 which does not require > you to do any previous setup! Just load it from configuration browser (pharo > 4 & 5) and it will start giving you feedback. More details can be found here: > https://github.com/Uko/QualityAssistant#quality-assistant-beta- > <https://github.com/Uko/QualityAssistant#quality-assistant-beta->. If you are > upgrading from older version, it is recommended to load QualityAssistant into > a fresh image, because multiple announcement and process changes may cause > exceptions in old objects. > > Even if you are an experienced programmer you can find QualityAssistant > useful for instantly spotting typos or making sure that you didn’t forget > some details about your code. > > Please give me a feedback about your experience, as I want to make it even > more useful. Either write me an email, or open an entry at: > https://github.com/Uko/QualityAssistant/issues > <https://github.com/Uko/QualityAssistant/issues> > > Have a nice week! > Uko > > > ___ > Moose-dev mailing list > moose-...@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
Re: [Pharo-dev] [Pharo-users] [Vm-dev] [ANN] Pharo 4.0 is released!
> On Apr 16, 2015, at 08:38, Sven Van Caekenberghe wrote: > > >> On 16 Apr 2015, at 11:55, Tudor Girba wrote: >> >> Great job! >> >> Thank you everyone for the contributions, support and trust. > > + 100 + 100 as well :-) Excellent news !!! ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] could the size of Playground be reduced a bit
Excellent solution, thanks! > On Mar 25, 2015, at 20:47, Tudor Girba wrote: > > Hi, > > In the latest GT-Playground and GT-Inspector you get the following behavior: > - you can resize the windows, and the windows spawned afterwards will > remember the dimensions, or > - you can explicitly specify the size you prefer in the settings browser. > > https://pharo.fogbugz.com/f/cases/14541/Editing-the-default-inspector-window-size > > <https://pharo.fogbugz.com/f/cases/14541/Editing-the-default-inspector-window-size> > > Cheers, > Doru > > > On Wed, Mar 25, 2015 at 11:43 PM, Peter Uhnák <mailto:i.uh...@gmail.com>> wrote: > oh resizing is already mandatory I am afraid. When the object inspected is > big, there is no other option but to resize the whole window. And many if not > most useful Pharo objects worth inspecting are big. > I rarely have to resize it (arguably I'm not using to full potential); but my > point was that there should be sensible defaults for both primary (most > common) use cases. You can never satisfy everyone 100%. > > Plus resizing windows is part of the experience of using a window GUI system. > As a long time user of dwm the very idea of resizing windows with mouse is > repulsive to me. (I still struggle in this respect with Pharo... but I have a > dream. :)) > > Peter > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow" ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] could the size of Playground be reduced a bit
+1 on that. Please make it less tall. It’s been a subconscious bother to me and now that Stef voiced it I realized it. > On Mar 25, 2015, at 14:57, stepharo wrote: > > Because it is a bit large now even on a 27 inch screen. > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
> On Mar 24, 2015, at 10:29, kilon alios wrote: > > [Spec] does not support custom made GUIs which is what I want That’s simply not true. Spec supports the embedding of whatever Morph you want inside your GUI. So you can easily mix and match your custom components with all the standard Spec components. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] Slots and MethodWrappers
I would say that they are different although related. Slots are for the interception of accessing instance variables (for read and write), and method wrappers for the interception of accessing methods (for execution). > On Mar 24, 2015, at 09:02, p...@highoctane.be wrote: > > I wondered how these two things are related. > > Will slots be giving MWs facilities out of the box? > > When should I use both? > > Phil > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] TextMorph scrolling the text on edit or selection operations
It would be very good to have a full test suite for Spec, but unit tests for UI stuff is complicated :-/ > On Mar 21, 2015, at 18:06, Peter Uhnák wrote: > > Also even though this was morphic issue, perhaps we should start adding tests > for spec since there are none. :( ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] TextMorph scrolling the text on edit or selection operations
Hi Ben, It’s noticeable if you use small windows a lot, like I do. I guess you must have a bigger screen than mine ;-) There is a description halfway down the thread on how to reproduce it, just before I uploaded the slice. Date is 19/08/2014 <https://pharo.fogbugz.com/f/cases/12569/TextModel-should-not-move-scroll-when-accepting-text#BugEvent.107762> > On Mar 22, 2015, at 09:00, Ben Coman wrote: > > Can't say that I noticed it. There is no information on that issue on how to > reproduce it. Sounds like you've got two use cases. Can you provide some > specific examples of these so I can observe the behaviour. > cheers -ben > > On Sun, Mar 22, 2015 at 3:19 AM, Johan Fabry <mailto:jfa...@dcc.uchile.cl>> wrote: > Hi all, > > I am assuming that I am not the only one that gets very annoyed when a > TextMorph scrolls the text when typing, such that the line I am typing is > always at the bottom, or scrolls the debugger when I am stepping over > instructions. I looked into this (bug > https://pharo.fogbugz.com/f/cases/12569/TextModel-should-not-move-scroll-when-accepting-text > > <https://pharo.fogbugz.com/f/cases/12569/TextModel-should-not-move-scroll-when-accepting-text> > actually) and I found a fix. > > But first I want to understand why the code is as it is. Anybody have any > idea why PluggableTextMorph>>setTextBasic: starts with scrollBar setValue: > 0.0. ?? If I remove this line the very annoying behavior is gone, and as far > as I can see there are no negative consequences on text handling (and > scrolling) in general. So I am wondering why it is there at all. > > A slice with my fix is in the inbox if you want to play a bit with it: > SLICE-Issue-12569-TextModel-should-not-move-scroll-when-accepting-text-johanfabry.1 > > Please have a look, this behavior has been getting on my nerves for quite > some time now … > > > ---> Save our in-boxes! http://emailcharter.org <http://emailcharter.org/> > <--- > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/~jfabry> > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
[Pharo-dev] TextMorph scrolling the text on edit or selection operations
Hi all, I am assuming that I am not the only one that gets very annoyed when a TextMorph scrolls the text when typing, such that the line I am typing is always at the bottom, or scrolls the debugger when I am stepping over instructions. I looked into this (bug https://pharo.fogbugz.com/f/cases/12569/TextModel-should-not-move-scroll-when-accepting-text actually) and I found a fix. But first I want to understand why the code is as it is. Anybody have any idea why PluggableTextMorph>>setTextBasic: starts with scrollBar setValue: 0.0. ?? If I remove this line the very annoying behavior is gone, and as far as I can see there are no negative consequences on text handling (and scrolling) in general. So I am wondering why it is there at all. A slice with my fix is in the inbox if you want to play a bit with it: SLICE-Issue-12569-TextModel-should-not-move-scroll-when-accepting-text-johanfabry.1 Please have a look, this behavior has been getting on my nerves for quite some time now … ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] files.pharo.org now cached close to you
That’s cool! Let’s hope it will help in downloading the latest image, sometimes it’s annoyingly slow here. > On Mar 6, 2015, at 05:58, Marcus Denker wrote: > > Hi, > > Yesterday we have set up a caching infrastructure for http://files.pharo.org > > This means that files that are requested multiple times from your location > will > be served from a server close to you. > > There are e.g. servers in Chile, Argentine, Brazil, Dallas, LA, Franfurt, > Paris, Hongkong, Sydney…. > > This will cost us around $1-2 per day. This is not a lot but more that > someone (e.g. me) could spend > from their own pocket. > > As such, this is only possible due to the funds of the Pharo Association: > > http://association.pharo.org > > Thanks a lot to all the members! > If you like this and want to support things like this, please consider > joining the association! > > fMarcus > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] The evil twin in 40516
This is excellent! > On Feb 26, 2015, at 20:07, Marcus Denker wrote: > > Hi, > > In 40516 there is now a strange, but rather powerful mechanism for > CompiledMethod: the Twin. > > What does that do? > > you can call on a method #createTwin > > (ReflectivityExamples>>#exampleMethod) createTwin. > > after this, the CompiledMethod has a high-level representation (the AST) > attached that itself references the CompiledMethod > (they form a twin). > > (ReflectivityExamples>>#exampleMethod) reflectiveMethod > > The fun thing is now that one can install either in the class. Call > #invalidate to make sure the reflective method is installed. > > ReflectiveMethod implements #run:with:in: which calls a compilation hook (too > re-create from the AST) and then installs that in the > method dict and then executes the method: > > (ReflectivityExamples>>#exampleMethod) createTwin. > (ReflectivityExamples>>#exampleMethod) invalidate. > self assert: (ReflectivityExamples>>#exampleMethod) class = > ReflectiveMethod. > self assert: ReflectivityExamples new exampleMethod = 5. > self assert: (ReflectivityExamples>>#exampleMethod) class = > CompiledMethod. > > Which means that this gives us an in-image, on-demand JIT compiler > AST->Bytecode. In 50 lines of code. > > e.g. try on Morph: > > Morph methods do: #createTwin. > Morph methods do: #invalidate. > > Counting which twin is installed shows us the working set of Morph: > > (Morph methods select: [ :each | each class = CompiledMethod ]) size > > some 330 method out of nearly 900…. > > So what can one do with this? In essence this turns the AST into a reflective > representation for Methods > (if you care to set up twin creation + invalidation correctly). > > What will this allow us to do? stay tuned... > > Marcus > > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] a lesson about pragma
I think that fundamentally you should not use pragmas for documentation. I guess that people use it to be able to provide minimal structure for their documentation. A better solution would be to have a simple convention for this kind of structure that is easy to parse, e.g using newlines to separate the ‘keywords’ and their ‘values’ and just have a comment. For example: Now: Comment convention: “ api: #block getter: #acceptBlock registration: #whenAcceptBlockChanged: " Easy to parse, and easy to write conversion logic for batch transformation of these comments. > On Feb 26, 2015, at 13:12, Ben Coman wrote: > > Could you provide a sample, so this anti-pattern is more clear. > cheers -ben > > On Fri, Feb 27, 2015 at 12:08 AM, stepharo <mailto:steph...@free.fr>> wrote: > We are cleaning spec and the fact that method selectors are used everywhere > in pragmas as meta description makes the navigation terrible. > I'm removing them to be able to understand who is really calling the methods. > So there is probably a lesson there. > > Stef > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] Spec terminology: renaming some terms
> On Feb 20, 2015, at 12:07, Sean P. DeNigris wrote: > > Henrik Sperre Johansen wrote >> If the goal is avoiding confusion to data model classes... > > Do we even need "Composable" in the name? This is relevant from a "where we > came from" standpoint, but to a new user, maybe it can be documented without > adding 10 characters to the class name… Sure, we could consider that … do you have any concrete suggestions? ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] Spec terminology: renaming some terms
Well, yes, I know what it is, I know about the building block idea behind it, and I know about the reusability. However, reflecting all of this in the name, ComposableModel, makes it unclear what it is for. This is what I got as feedback of people: they did not even understand that this is what you subclass to define your UI. So apparently this is confusing and not the way to go. Using ‘Widget’ in the name is not really a good idea either, because then people will think that it is for parts of an UI only, not complete UI’s. That’s more confusion. > On Feb 19, 2015, at 20:23, Nicolai Hess wrote: > > But this *is* a model, not a UI. Yes a model for the UI, but still, the real > UI-View is what comes through the Spec interpreter. > "UI" sounds like "the whole user interface", but Specs ComposableModels are > meant as "building blocks". > > > UI-Model -> WidgetAdapter -> Widget/View. > > I would prefer (in this order): > 1. ComposableModel (because this is the current name) > 2. ComposableWidgetModel (widget: a brick or part of an UI) > 3. ComposableUIModel > 4. ComposableUI > > I am not fully against 4., because it is the goal of spec to build reuseable > UIs. > For example for a Spec based "ListSelectionDialog" we can reuse the whole > component, not only the model, not only the view, but the > whole component with interaction between the list and other controls. > But I would prefer ComposableWidgetModel, because a "Widget" > (button/textfield/list) is the smallest unit of a user interface > representable with Spec. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] Spec terminology: renaming some terms
The problem is that people are confused by the term Model, so they will also be confused by Logic. I want to remove the confusion and make clear that it is a user interface (and that it is composable by default) -> ComposableUI. It could also be ComposableUserInterface but we do not win anything by that name, as UI is a standard acronym + we would have to type more when subclassing it. So I prefer ComposableUI. > On Feb 19, 2015, at 14:37, stepharo wrote: > > I know :) > So may be Logic because this is the logic of the application. > > Stef > Le 19/2/15 18:16, Sven Van Caekenberghe a écrit : >> Well, it means User Interface ;-) >> >> The thing that got everybody confused is precisely the word Model, if we >> keep that the confusion will continue. >> >>> On 19 Feb 2015, at 18:11, stepharo wrote: >>> >>> Hi Johan >>> >>> For me UI does not mean anything. >>> So may be ComposableUIModel? >>> Or ComposableUILogic >>> >>> >>> Stef >>> >>> Le 19/2/15 13:22, Johan Fabry a écrit : >>>> Hi all, >>>> >>>> I don’t read mails on pharo-dev usually, so sorry if this has been >>>> discussed before (and then pointers to the discussion would be >>>> appreciated). >>>> >>>> Last week, in Pharo-users I proposed the Spec terminology changes below. >>>> Responses were positive. I am willing to volunteer to do that next week so >>>> it’s finished before the 28th and it’s included in Pharo 4. And then I >>>> will update the documentation as well. But first I want to know if there >>>> are any objections from people on this list. >>>> >>>> I propose to rename: >>>> - ComposableModel to ComposableUI >>>> - all the protocols ‘protocol-*’ to ‘API-*’ >>>> >>>> Other renaming-related comments are also welcome. >>>> >>>> ---> Save our in-boxes! http://emailcharter.org <--- >>>> >>>> Johan Fabry - http://pleiad.cl/~jfabry >>>> PLEIAD lab - Computer Science Department (DCC) - University of Chile >>>> >>>> >>>> >>> >> >> > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
[Pharo-dev] Spec terminology: renaming some terms
Hi all, I don’t read mails on pharo-dev usually, so sorry if this has been discussed before (and then pointers to the discussion would be appreciated). Last week, in Pharo-users I proposed the Spec terminology changes below. Responses were positive. I am willing to volunteer to do that next week so it’s finished before the 28th and it’s included in Pharo 4. And then I will update the documentation as well. But first I want to know if there are any objections from people on this list. I propose to rename: - ComposableModel to ComposableUI - all the protocols ‘protocol-*’ to ‘API-*’ Other renaming-related comments are also welcome. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Moose-dev] OpenStreetMap integration
Very cool indeed !! > On Jan 19, 2015, at 15:19, Alexandre Bergel wrote: > > Dear All, > > This week end I have integrated the excellent work of Onil Goubier and > Thierry Goubier. They have worked on a bridge between OpenStreetMap and > Roassal. As a result, you can easily decorate a map with element describing > metrics and properties of geolocation. Consider the following: > > I think the following screenshot should be self-explanatory: ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] improving print-it in playground
Yes, the print-it now is much better than the classic ST behavior! I appreciate the latest feature of being able to get the response as commented text. I have needed that in the past, sporadically. (But I don’t remember specific cases, sorry.) > On Jan 19, 2015, at 08:33, Tudor Girba wrote: > > Hi, > > I worked with Andrei to find a solution for improving the print-it support. > You can take a look here: > http://www.humane-assessment.com/blog/improving-print-it-support-in-gtplayground > > <http://www.humane-assessment.com/blog/improving-print-it-support-in-gtplayground> > > The current solution can be found in the latest Pharo image. > > Cheers, > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow" ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Esug-list] [Pharo-users] [ann] gtspotter: a moldable interface for spotting objects
OK now I get it … thanks for clarifying! I think my confusion stems from the use of ‘category' and then talking about 'the collection object’, which made me think about collections and source code and protocols and packages and I got lost. I think that the sentence of the blog would be clearer like this (uppercase to show changes): To do this, GTSpotter offers an extra action: diving in a RESULTS category. Pressing Cmd+Shift+ArrowRight dives in the collection OF RESULTS OF that category. Thus, we can continue refining the search inside the category. So then, my suggestion for a legend at the bottom of the results list would be: Cmd+Shift+ArrowUp/ArrowDown = Next/Prev category, Cmd+RightArrow = Dive into Result, Cmd+Shift+RightArrow = Dive into Category > On Dec 8, 2014, at 12:48, Tudor Girba wrote: > > Hi, > > Ok. Let's take it step by step and see if we cannot find a better way of > explaining. > > Take a look at the first picture in the blog post. Entering GTSpo shows > results both for Classes and for Packages. These "Classes" and "Packages" are > what we call search categories, and they have associated a query processor > that can populate them with results (see the "Spotting your objects" section > from the bottom of the post). > > In our case, we get 39 classes (of which only 5 are shown) and 1 package that > match the query. If you want to look at all those 39 classes, you can dive in > the whole collection behind the category in a separate step. This is achieved > through Cmd+Shift+ArrowRight. Does it make more sense now? > > I did not consider the category to be confusing. Would you propose another > name? > > Cheers, > Doru > > > On Mon, Dec 8, 2014 at 4:02 PM, Johan Fabry wrote: > Sorry, but no :-( > > I am always confused when people say ‘category’ because the word has so many > overloaded meanings. The same happens in the blog post, it is not clear to me > what category means here, and what does it have to do with the collection > object? > > > On Dec 7, 2014, at 11:16, Tudor Girba wrote: > > > > Hi, > > > > Yes, we will still evolve the UI. At the very least you will get the > > shortkeys directly on the actions. > > > > The answer to your question is in the blog post: > > GTSpotter offers an extra action: diving in a category. Pressing > > Cmd+Shift+ArrowRight dives in the collection object containing only the > > items from that category. Thus, we can continue refining the search inside > > the category. > > > > So, you will open the collection of that sub-category and you will see more > > items at once (not just 5). Is it clearer now? > > > > Cheers, > > Doru > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Esug-list] [Pharo-users] [ann] gtspotter: a moldable interface for spotting objects
Sorry, but no :-( I am always confused when people say ‘category’ because the word has so many overloaded meanings. The same happens in the blog post, it is not clear to me what category means here, and what does it have to do with the collection object? > On Dec 7, 2014, at 11:16, Tudor Girba wrote: > > Hi, > > Yes, we will still evolve the UI. At the very least you will get the > shortkeys directly on the actions. > > The answer to your question is in the blog post: > GTSpotter offers an extra action: diving in a category. Pressing > Cmd+Shift+ArrowRight dives in the collection object containing only the items > from that category. Thus, we can continue refining the search inside the > category. > > So, you will open the collection of that sub-category and you will see more > items at once (not just 5). Is it clearer now? > > Cheers, > Doru ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] [ann] gtspotter: a moldable interface for spotting objects
Hola, Andrei demoed it to me on friday and it is *extremely* cool. I can’t wait to start using it for my next development session. I have one request though (as I already mentioned to Andrei). Since you are using a significant part of the screen, it would not be costly to (e.g. at the bottom) put a small legend of the non-obvious keystroke combinations. It would greatly increase discoverability of the features of the tool. Considering the blog post, the legend would be ( I don’t understand the difference between the last 2): Cmd+Shift+ArrowUp/ArrowDown = Next/Prev category, Cmd+RightArrow = Dive into, Cmd+Shift+RightArrow = ??? > On Dec 7, 2014, at 10:14, Tudor Girba wrote: > > Hi, > > Alex Syrel, Andrei Chis and I are happy to announce a new addition to the > Glamorous Toolkit: > GTSpotter, a novel interface for spotting objects. > > GTSpotter has two goals: > - Provide a uniform yet moldable interface that can work on any object, and > - Handle searching through arbitrary levels of object nesting. > > We think this will have a significant impact on the development workflow in > Pharo. > > Here is a couple of screenshots: > > > > > A trailer is available here: > https://www.youtube.com/watch?v=PhSmjR3NOlU > > A detailed description is available here: > http://www.humane-assessment.com/blog/introducing-gtspotter > > It works already in Pharo 3.0 and can be played with by following the > instructions from: > http://gt.moosetechnology.org > > Please let us know what you think. > > Enjoy, > The Glamorous Team ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] [Article] Reddit.st - In 10 Cool Pharo Classes
Whoa, another cool tutorial article of yours. Excellent work! I have a question: I was thinking about giving the HP-35 article and this article to some CS students of mine that have 0 Smalltalk experience, to get them up to speed. But the tutorials are missing the basic explanation of the use of workspaces and browsers, and I don’t know where to get some documentation that treats just that. Any pointers to that kind of material? TIA, On Sep 1, 2014, at 5:18 PM, Sven Van Caekenberghe wrote: > Hi, > > I published another introduction/tutorial article > > Reddit.st - In 10 Cool Pharo Classes > > Implementing a Reddit style web application in Pharo using Seaside, Glorp and > PostgreSQL > > https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740 > > The focus is not so much on the smaller size or the higher developer > productivity in Pharo, but more on the fact that we can cover so much ground > using such powerful frameworks, as well as the natural development flow from > model over tests and persistence to web GUI. This is a more intermediate > level article that assumes basic knowledge about Pharo (language and IDE). > > https://ci.inria.fr/pharo-contribution/job/Reddit/ > > http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/Reddit > > Enjoy! > > Sven > > PS: This article is actually an update of an article that I wrote in 2010 and > that became unavailable/outdated. > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] Your success stories ...
Hi, I just looked at this page (Firefox 31, Mac OSX 10.9.3) and the images are zoomed like 500%, they are huge. I think this is not the intent, it would be good if this is looked at. Greetings, On Jul 31, 2014, at 2:12 AM, stepharo wrote: > "Pharo success stories" is getting started at > >http://www.pharo.org/success > > TrentoSur http://trentosur.com looks so sexy > > Please send me information about yours they will be added to the pending queue > > Stef > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Moose-dev] rethinking the print it action in Pharo
That looks like a cool re-imagining of the print-it ! On Jul 27, 2014, at 7:33 PM, Tudor Girba wrote: > Hi, > > In the course of revamping the Pharo environment, we stumbled across the > print it action and we (Andrei and I) decided to rethink it. > > > You can find more details here: > http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo > > Let us know what you think. > > Cheers, > Doru > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > ___ > Moose-dev mailing list > moose-...@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
Re: [Pharo-dev] [Moose-dev] [ann] beacon - a slim announcement-based logging engine
That looks very cool! I agree that logging objects is the way to go, and now that we have all this infrastructure we should be able to better make use of object-based logs. I was just thinking about this issue a couple of weeks ago, and beacon might just be the solution for me. I hope to find the time in a few weeks to start using it! On Jun 15, 2014, at 9:04 AM, Tudor Girba wrote: > Hi, > > I like very much the new energy people are putting into creating the > SystemLogger engine for Pharo. I think this is a specifically important area > for which we have to have a solution out of the box. At the same time, I also > think that Pharo provides an infrastructure that makes room for ideas that > are otherwise hard to reach in other languages or environments. > > Stef asked for collaborations around this project, so here is my literally > small contribution: a rather different logging engine. It is called Beacon, > it is based entirely on Announcements, it has ~200 lines of code, it has no > tags or levels, and in my opinion it is fully functional. > > You can see a detailed description here including some informal comparisons > with SystemLogger: > http://www.humane-assessment.com/blog/beacon > > Please let me know what you think. I would be happy to join forces to reach a > mature solution that is both versatile and that can show how Pharo is > different. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > ___ > Moose-dev mailing list > moose-...@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
Re: [Pharo-dev] [Moose-dev] CodeCity and Spec
Hola, AFAIK there are no plans for that. Maybe there is an alternative: there is a Roassal2 adaptor for Spec, Roassal2Spec package, which should now come with Roassal2. It allows you to have any Roassal2 visualization as a Spec ComposableModel. On Jun 13, 2014, at 4:47 AM, Yuriy Tymchuk wrote: > Hi all, > > are there any suggestions for integrating CodeCity into Spec? E.g. using > CodeCity visualisation in a view build by Spec. > > Uko > ___ > Moose-dev mailing list > moose-...@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
Re: [Pharo-dev] [Pharo-users] New Website online
Slick! Congrats on the site. On Apr 30, 2014, at 10:26 AM, Marcus Denker wrote: > Hi, > > The new website is online! > > http://pharo.org > > For now, pharo-project.org still is the old website. > Next: pharo-project.org should forward to pharo.org, > it will still be available as old.pharo-project.org for some time. > > Thanks a lot to > Nico http://nicolas-petton.fr, > Esteban http://smallworks.eu, > Damien http://damiencassou.seasidehosting.st > and Aurelia http://aurelia.saout.fr > > > Marcus > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Pharo-users] Pharo 3.0 Released!
And a big +1 on that! On Apr 30, 2014, at 11:01 AM, Sven Van Caekenberghe wrote: > Today is a great day ! > > I am really proud to be part of this community and thankful for the > contributions and hard work of so many people. > > This is a very important milestone while the future looks even brighter. > > Sven > > On 30 Apr 2014, at 16:01, Esteban Lorenzano wrote: > >> Dear World, >> >> Pharo 3.0 (http://www.pharo.org) is here. >> >> >> >> The past year seemed short as we got busy building more than usual. Many >> things have changed in Pharo. Here are the highlights: >> - The new modular Opal compiler is now the default compiler used in the >> system. >> - The Athens vector graphics canvas is now integrated and it supports Cairo >> rendering on all platforms. >> - Many tools have been rewritten using Spec, a new framework for building >> user interfaces. >> - Versionner and Kommiter are two of the new development tools. >> - RPackage, a new package mechanism got enhanced with tags and is fully >> integrated in the system. >> - The debugger model was rewritten to become modular, the inspector received >> a bump to support multiple views, and the Nautilus code browser supports >> tags, search and lot more improvements. >> - Morphic has seen many cleanings and improvements and the visual theme has >> been revamped. >> >> These are just the more prominent highlights, but the details are just as >> important. We have closed 2364 issues in Pharo 3 (compared with 1727 issues >> in Pharo 2). Take a moment to go through a more detailed recount of the >> progress: >> >> https://github.com/pharo-project/ChangeLogs/blob/master/Pharo30ChangeLogs.md >> >> Pharo is improving on many fronts. Just take a look at the code city of >> Pharo (built with Pharo for Pharo). Every building is a class, and the red >> bricks represent the modified methods in Pharo 3. >> >> >> >> Many things are changing but the system gets more stable. Moving from Pharo >> 2 to Pharo 3 is almost a matter of just loading the code. >> >> Remember that Pharo is your platform. We thank all the contributors of this >> release: Jean-Baptiste Arnaud, Simon Allier, Philippe Back, Clément Bera, >> Alexandre Bergel, Torsten Bergmann, Usman Bhatti, Vincent Blondeau, Noury >> Bouraqadi, Johan Brichau, Camillo Bruni, Sven Van Caekenberghe, Damien >> Cassou, Nicolas Cellier, Guido Chari, Dimitris Chloupis, Bernardo Contreras, >> Ben Coman, Gabriel Omar Cotelli, Jordi Delgado, Tommaso Del Sasso, Gisela >> Decuzzi, Christophe Demarey, Sean DeNigris, Marcus Denker, Martin Dias, >> Erwan Douaille, Stephane Ducasse, Stephan Eggermont, Pablo Estefo, Luc >> Fabresse, Johan Fabry, Hilaire Fernandes, Nahuel Garbezza, Leo Gassman, >> Lucas Giudice, Tudor Girba, Thierry Goubier, Norbert Hartl, Dale Henrichs, >> Pablo Herrero, Nicolai Hess, Andre Hora, Alejandro Infante, Ricardo Jacas, >> Henrik Sperre Johansen, Denis Kudryashov, Pavel Krivanek, Juraj Kubelka, >> Laurent Laffont, Jannik Laval, Max Leske, David Lewis, Diego Lont, Esteban >> Lorenzano, Stefan Marr, Mariano Martinez Peck, Roberto Minelli, Hernan >> Morales Durand, Eliot Miranda, Fernando Olivero, Nicolas Papagna Maldonado, >> Nick Papoylias, Nicolas Passerini, Vanessa Peña, Nicolas Petton, Alain >> Plantec, Guillermo Polito, Damien Pollet, Jochen Rick, Benjamin Van >> Ryseghem, Ronie Salgado, Camille Teruel, Juan Pablo Sandoval Alcocer, Samir >> Saleh, Frank Shearar, Igor Stasenko, Aliaksei Syrel, Sebastian Tleye, Yuriy >> Tymchuk, Andres Valloud, Martin Walk, Hernan Wilkinson. >> And many many more who contributed indirectly, by reporting bugs, >> participating in discussion threads, providing feedback... >> >> Pharo 3.0 is the largest step we took since we started. Yet, it’s just a >> step. Expect more. Much more. >> >> Enjoy! >> The Pharo Team > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] [Moose-dev] [Pharo-business] [ANN] DBPedia: Query Wikipedia from Pharo
+1 to that! It would be good to have some kind of uniform syntax for constructing queries. Especially now that the use of JSON objects is quite common. The OP was actually referring to MongoQueries. To get some examples of the syntax see section 4 of https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/Voyage/Voyage.pier.html On Mar 3, 2014, at 10:13 AM, Alexandre Bergel wrote: >> What would be nice is to have an abstraction like mongoTalk on top to avoid >> to manipulate strings but to manipulate query elements. > > That is a nice idea. > > Alexandre ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
[Pharo-dev] [ANN] Spec documentation in PFTE book finished
Hi all, I am happy to announce that Ben and I finished the documentation of Spec for the Pharo For The Enterprise book. This documentation is up-to-date with the latest version of Spec, and is focused towards people wanting to use it and even extend it (in contrast to the academic papers which are … academic ;-) ). I hope that this text will help all the people that are building UIs in Pharo, and it will clear up any doubts that they may have. The chapter is available in source form from the GitHub project of the PFTE book: https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english The easiest way to read the chapter is from the continuous integration server, which produces a html file of the chapter here: https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/Spec/Spec.pier.html (The same server also produces pdf and markdown files, but there are some strange artifacts there, currently. I guess this will be cleared up in the future) We tried our best to make it understandable and complete, but if you have any doubts or comments please do not hesitate to let us know !! Ben prefers Github apparently, but if you are oldskool like me you can also send a mail (privately or to the mailing list). Now it's time to build some cool user interfaces! :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
On Feb 1, 2014, at 8:59 PM, Pharo4Stef wrote: >>> If your students have problems to grasp the concept of pool dictionaries >>> then how do they deal with mathematics and computer science? >> >> Given enough time, no problem. But time in class and outside is limited >> enough as it is. > > No johan even if I multiply by two the amount of time you have you will not > spend time on such uninteresting concept when > we have so much more beautiful concepts to show. There is a difference between being able to do it, and me wanting to to it :-). I don't want to because of the same reasons as you, apparently. I am just defending my students here :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
On Feb 1, 2014, at 12:55 PM, Andreas Wacknitz wrote: >> There are some kinds of students who are going to find Smalltalk difficult, >> yes. I do not see how removing pooldictionaries from the class creation >> template will affect them. If they ask about them, you can say that they are >> there and point them to the new class creation message. And take advantage >> of that to say that class creation is just a message send while you are at >> it :-) > > If your students have problems to grasp the concept of pool dictionaries then > how do they deal with mathematics and computer science? Given enough time, no problem. But time in class and outside is limited enough as it is. >> You still have the freedom to use pool dictionaries. They are still there. > They are hidden for the sake of simplicity for some students. > I want my pool dictionaries back :-D For simplicity of everybody that is learning the language, and everybody that writes a class without pool dicts. Note that they are still there! Just write pooldictionaries: in the next-to-last line and done. >>> Obscuring things is sometimes a good design strategy, but here there is a >>> well known artefact breaking tradition here, that isn’t something light. >>> And the proposed alternative design is far to be better (read: have been >>> proven itself worth of its added burden of breaking that tradition) >> >> So if we cannot break tradition then Traits should never have been >> introduced? > Traits are a different kind of thing. They didn’t cripple existing elements > in Pharo. The only problem was the lack of tool support when they were > introduced. You are comparing apples and oranges. I repeat. Nothing is broken. Pool dictionaries are still there. So the comparison stands. >>> Yeah, you’re not the only one with that perception. >>> >>> This move sucks. It allegedly solved a problem that allegedly happens to >>> some by creating a problem for almost everybody. >> >> I have an issue with your "problem for almost everybody" statement. >> Pooldictionaries are rarely used. Look at the classes in the image. Can you >> argument why this then is a problem for almost everybody ? I do not see how >> you get to this conclusion. > For generations of Smalltalk newbies it was possible to either grasp the > concept or ignore it. > Why do you need to change this without a real solution for those who want to > use them? > In my eyes it’s an absolute minority of Pharo users who aren’t able to > understand the concept. The problem is not understanding the pooldictionaries. The problem is the people that use them. Are you saying that it is a problem for everybody that the template is now without a line that they do NOT use? In that case we should not touch anything and not make any changes. >> This half-assed non-solution is the same solution as for Traits, >> essentially. Do you have the same issue with Traits? >> > Again you are comparing apples and oranges. Traits didn’t take away anything > but brought something new. > You took away something. I repeat. Pool dictionaries are still there. I did not take away anything. Essentially I am doing the same as with traits: if you use them you see them, if not, not. The comparison stands. > BTW how do your students cope with Traits? They must be completely > overwhelmed. > And how do you teach the class hierarchy and meta classes? Yes, I do teach them because I have the *time* to do it. I have the time to do it because I can focus on the essential and not lose it explaining obscure features. >> Please see previous mail. > > I am a close lurker of the mailing lists and I completely missed it. Sent today at 10:37 AM chilean time, a few minutes before I sent the mail you are replying to. Same subject as this mail. For completeness, here is the content: > For what it's worth: this was asked on the users list (some months ago). > There were about 5 replies and they were positive. I do not recall having any > negative replies. > > I think that asking much more than that is hard, given the nature of mailing > lists and the comity being busy with many other things. > > Also, having learned about user studies and performed a few (for this > "science" thing I'm supposed to be doing), I can tell you that getting a > really representative group of users together is nearly impossible in the > scenario we are in. So anything you can get out of an inquiry will just be > 'some people say: OK'. Nothing is guaranteed about other people. Which is > just what is happening here ! ;-) > > On Jan 31, 2014, at 6:43 PM, Sebastian Sastre > wrote: > >> Lets says it convinces you… >> >> Time to be skeptic. Test. >> >> Test with someone else. Tests it with 5 guys and ask how they feel about it. >> >> Hear. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
On Feb 1, 2014, at 12:39 PM, "Torsten Bergmann" wrote:
> OK, back to topic and to summarize: we now all fully understood that the
> original message
> including pools is still there, will not break code loading or other things
> and that the
> change is on the Nautilus level.
Yes, thanks for understanding and summarizing well.
> But still the simple question left to be anwered here: what will this change
> of reducing the
> class template in the default browser give us? What problem did it really
> solve?
>
> The answer given so far is that it may be problematic when teaching because
> you want to
> introduce to language features step by step. But you said yourself in your
> own post
> that
>
>
>It is BORING to have to say to kids:
> - do not care of classvar
> - do not care of pooldictionaries
>
>
> So my question: if you are bored of the "complexity" of BOTH (!)
> - why do we hide pools now
> - and leave class variables still left in the template?
>
> I really do not understand because with the change it now looks in
> Pharo3.0 Latest update: #30732 like this:
>
>Object subclass: #Foo
> instanceVariableNames: ''
> classVariableNames: ''
> category: 'Bar'
>
> So why do we keep class vars then? According to your mail we would have to
> remove them too.
From my point of view this is a different design decision to take since it is a
different feature of the language. So it is not included in the change that I
proposed. And BTW I leave it to somebody else to make the call and propose a
change to Pharo that addresses this (or not, as may be the case).
> Additionally this change violates the intention of a template (which one
> usually just has to fill out)
> and one now has to remember the original full keyword and have to type it in
> again - which is IMHO
> really awkward and stupid.
>
> So with all respect: I still can not see the introduction of the reduced
> template as a step forward
> or an improvement.
For me, this reduces to the case of Traits. A low usage (arguably), so uses: is
not present in the template. We do the same for pooldictionaries. If you are
against this, and say that you should just fill in the template, then logically
you should be against how Traits are handled. Following that logic, you are
advocating for:
Object subclass: #NameOfSubclass
uses: ''
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: ''
Am I correct?
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
On Feb 1, 2014, at 10:58 AM, Sebastian Sastre wrote: > > On Feb 1, 2014, at 11:37 AM, Johan Fabry wrote: > >> For what it's worth: this was asked on the users list (some months ago). >> There were about 5 replies and they were positive. I do not recall having >> any negative replies. >> >> I think that asking much more than that is hard, given the nature of mailing >> lists and the comity being busy with many other things. > > Yeah we are totally exposed to the problem of having ~null usability tests so > our UI are non-designers attempts to get it incrementally right > > That’s a hard one. > > We really need help from design universities students Yes, something like this would be great. If it's a consolation: this kind of problem is present throughout the programming language research community. There's a great paper by Hanenberg on that. It's called "Faith, hope, and love: an essay on software science's neglect of human factors". (OOPSLA 2010) Well worth the read! ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
On Feb 1, 2014, at 9:32 AM, Sebastian Sastre wrote: >> I don’t give any lectures to students but I often try to „teach“ Smalltalk >> to some of my colleagues and friends. And with that I have hard times. >> Typically „experienced“ software developers think about themselves as being >> experts in object orientation and programming languages, >> even if they have only experiences with C, C# and C++. „Teaching“ them about >> Smalltalk’s idea of object orientation is VERY hard, almost >> impossible because they already know everything (read: they are ignorant) >> and lazy. I guess there are some similarities to students. > > +1 on this There are some kinds of students who are going to find Smalltalk difficult, yes. I do not see how removing pooldictionaries from the class creation template will affect them. If they ask about them, you can say that they are there and point them to the new class creation message. And take advantage of that to say that class creation is just a message send while you are at it :-) >> Newcomers don’t use a lot of things but that should not be a reason to hide >> them. In my experience newcomers need guidance and rules but >> „oldtimers“ need freedom. This is one of the reasons I really enjoy dynamic >> typing and Smalltalk. I don’t like to obey to artificial rules that only >> put permanent burden to me in order to protect me from something I might do >> wrong sometimes. You still have the freedom to use pool dictionaries. They are still there. >> At the moment I am considering pool dictionaries for a solution of a problem >> at hand: I need to collect some information (warnings, errors, and reports) >> over lots of related and unrelated classes. For the moment I have >> parameters, but that is getting inconvenient with a growing number of things >> to collect… >> So, if you need something it should be there and not necessarily obscured >> and hidden! >> > > If you don’t see features you don’t know what the machine can do for you. > > Obscuring things is sometimes a good design strategy, but here there is a > well known artefact breaking tradition here, that isn’t something light. And > the proposed alternative design is far to be better (read: have been proven > itself worth of its added burden of breaking that tradition) So if we cannot break tradition then Traits should never have been introduced? > Students shouldn’t be underestimated they can handle ignoring what they don’t > need, no problem If I would have infinite time, and they as well, sure! Be we don't and we need to focus. >> Yes, but it’s not there yet but this change already took away some power >> without giving me back something in exchange! >> I am able to ignore some parts of class creation message easily (I also >> don’t use class variables that often) and I don’t see why students >> shouldn’t be able, too. Quite contrary I think if you hide these things from >> students they won’t see it, won’t get curious and in the end will only >> learn the boring parts of Smalltalk… >> > Yeah, you’re not the only one with that perception. > > This move sucks. It allegedly solved a problem that allegedly happens to some > by creating a problem for almost everybody. I have an issue with your "problem for almost everybody" statement. Pooldictionaries are rarely used. Look at the classes in the image. Can you argument why this then is a problem for almost everybody ? I do not see how you get to this conclusion. > It’s a half-ass non-solution > > Do you really love cleaning that up? This half-assed non-solution is the same solution as for Traits, essentially. Do you have the same issue with Traits? > The second part of your homework on this design decision was completely > ignored so expecting it to be loved (popular) is unrealistic > > And by not doing that you just added a problem where there was none > > Not willing to do that second part? > > Then don’t fix what isn’t broken. Please see previous mail. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
Please note that the change IS at the Nautilus level. The default class description is the same as before! Your class porting example is unharmed by this change. On Feb 1, 2014, at 7:16 AM, GOUBIER Thierry wrote: > Shortening the default class description is also painfull when you port code, > because it makes the class appear different (description with and without > pool dictionaries) in the change sorter. I wrote a pac change reader to port > SmaCC from Dolphin to Pharo, and, really, this kind of change makes that > unusable. > > In short, make that change correctly: at the Nautilus level. It's a GUI > issue, not a language issue. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
+1 on this point of view On Feb 1, 2014, at 7:09 AM, Pharo4Stef wrote: > @ Igor > > I guess that I know pretty well poolDictionaries I do not need an > explanation. I even found bugs in the previous lookup and now > we have recompilation bugs when changing pools. > > Now how many times gave one lectures to newcomers? > Why do we have new calling initialize? Because after first lecture we HAD to > explain metaclasses. > Do we want to continue to stay a close club of smart asses? > > NO > > NOT ME at least > > > @others > > Now people hear me well: you are ready to hear well. Lower the music > > WE WILL change the class definition in Pharo 4 because we want slots. > So be prepared. > > This is not because you did not read nor type this class definition since > years (because you do not even > look at it) that > - it will not change > - students do not get overhelmed with it. > > I DO NOT WANT MY SONS TO PROGRAM IN PYTHON/RUBY/JS BECAUSE THIS IS “EASIER”. > Is it clear? > It is BORING to have to say to kids: > - do not care of classvar > - do not care of pooldictionaries > > COME ON when can we open our eyes? > So yes I’mad at the lack of vision **you** have. But do not worry I have the > vision for Pharo. If you do not like it, I cannot do > much for you. Continue rambling how cool was smalltalk 30 years ago. Not me. > We are INVENTING the future here. > > So please focus your energy on how to make pharo simpler, nicer and sexier. > > Stef > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
On Jan 31, 2014, at 4:50 PM, Pharo4Stef wrote: >> I don’t see how this change make Smalltalk (the language) simpler. For me >> this change looks more like an obfuscation than a simplification. > > How many lectures did you give? It is annoying to have to explain something > that usually people do not need to know. To complement this: in my own experience as a full-time prof, whenever you are teaching and at a given point you need to say: 'I cannot explain this yet' or resort to handwaving there is something wrong. Do I need to explain pooldictionaries to be able to talk about class creation? No, I should not need to do that. I get this feeling with Java all the time. First hello world example in Java is always a mess. public static void main(String[] args) OMG. Start to explain all that just to do a println? Were is the simplicity there? I don't want to have this kind of feeling when I explain Smalltalk. >> How should newcomers know how to enter pool dictionaries? I rarely use pool >> dictionaries and if I will need it I surely have forgotten about >> this change and expect irritation and frustration. > > Newcomers do not use pooldictionaries. In 10 years smalltalking I used them > twice. I agree with Stef that pooldictionaries are advanced features. I have been Smalltalking since 1998 and I have never used them. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
For what it's worth: this was asked on the users list (some months ago). There were about 5 replies and they were positive. I do not recall having any negative replies. I think that asking much more than that is hard, given the nature of mailing lists and the comity being busy with many other things. Also, having learned about user studies and performed a few (for this "science" thing I'm supposed to be doing), I can tell you that getting a really representative group of users together is nearly impossible in the scenario we are in. So anything you can get out of an inquiry will just be 'some people say: OK'. Nothing is guaranteed about other people. Which is just what is happening here ! ;-) On Jan 31, 2014, at 6:43 PM, Sebastian Sastre wrote: > Lets says it convinces you… > > Time to be skeptic. Test. > > Test with someone else. Tests it with 5 guys and ask how they feel about it. > > Hear. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
On Jan 31, 2014, at 2:03 PM, Andreas Wacknitz wrote: > > Am 31.01.2014 um 14:40 schrieb Johan Fabry : > >> Hi Torsten, >> >> I think it is a design decision / tradeoff, and therefore there is no >> fundamentally "right way" to do it. For me, it is the same case as the uses: >> message for Traits. It's not in the template by default because it is used >> very infrequently. So for language simplicity it should not be there. For >> me, simplicity is one of the core points of Smalltalk so this is why I feel >> strongly about it. > > I don’t see how this change make Smalltalk (the language) simpler. For me > this change looks more like an obfuscation than a simplification. It's simpler because very infrequently used things are not immediately exposed. Again this is a matter of where the design tradeoff is made. If it would be used a lot it would indeed be obfuscation. >> When I say "very infrequently", this is of course a fuzzy metric, I know. >> And I understand that you do not agree with this design decision. >> >> But on the other hand, I don't think that it is too hard to remember where >> to add the pooldictionaries: line if you need it, and the old message with >> this line still works, so all old examples still work. > > How should newcomers know how to enter pool dictionaries? I rarely use pool > dictionaries and if I will need it I surely have forgotten about > this change and expect irritation and frustration. I understand that when you want to use it and it is not there there is a cost. Especially if you have forgotten how the message goes. BUT it is a message send, just like any other in Smalltalk. Open a method finder and look for methods with pooldictionaries in there. In 15 seconds you find it. I think that is an acceptable period of time of irritation and frustration. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
I would like to get to the bottom of this, to be doubly sure there is no remaining problem. Can you send me privately the steps to reproduce so I can have a go at it using the unfixed version? On Jan 31, 2014, at 2:04 PM, Esteban Lorenzano wrote: > No, because my pools were not there and my tests were failing. But no > matters, it works now :) > >> On 31 Jan 2014, at 17:45, Johan Fabry wrote: >> >> >> What probably happened is that Monticello loading with pooldictionaries was >> still working, but Nautilus was not showing them. This is the only thing >> that changed, and the fix addresses the showing part. So you should not >> worry. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
What probably happened is that Monticello loading with pooldictionaries was still working, but Nautilus was not showing them. This is the only thing that changed, and the fix addresses the showing part. So you should not worry. On Jan 31, 2014, at 1:26 PM, Esteban Lorenzano wrote: > I don’t know what happened. All that I know is that it was not working and > now with the last fix it is, so I’m happy for now. > worried? yes. But not too much :) > > On 31 Jan 2014, at 14:59, Henrik Johansen > wrote: > >> >> On 30 Jan 2014, at 6:14 , Esteban Lorenzano wrote: >> >>> So… that. >>> >>> Is super cool to remove poolDictionaries from the default class template. >>> What is not cool *at all* is the fact that now my low level projects, who >>> uses them intensively, does not work anymore. >>> The reason? the classes are created without poolDictionaries. >>> >>> So, please… whoever pushed this change. Please fix it. >>> >>> thanks, >>> Esteban >> >> Sooo, since I’m curios, anyone care to explain how a change intended to >> affect whether Nautilus displays pool Dicts end up breaking how they’re >> loaded from Monticello? >> >> Did Nautilus pick up on the class load announcement from RPackage and end up >> recompiling the class with it’s own (lacking) default definition or >> something similarly crazy? >> >> Cheers, >> Henry > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
Hi Torsten, I think it is a design decision / tradeoff, and therefore there is no fundamentally "right way" to do it. For me, it is the same case as the uses: message for Traits. It's not in the template by default because it is used very infrequently. So for language simplicity it should not be there. For me, simplicity is one of the core points of Smalltalk so this is why I feel strongly about it. When I say "very infrequently", this is of course a fuzzy metric, I know. And I understand that you do not agree with this design decision. But on the other hand, I don't think that it is too hard to remember where to add the pooldictionaries: line if you need it, and the old message with this line still works, so all old examples still work. The fix I proposed was integrated today, so everything should work now. If there still is a problem I will provide a fix as soon as I get notified of the issue (as I did yesterday). My apologies to all for the mess, I promise I won't cause such a mess again in the future. On Jan 31, 2014, at 9:54 AM, "Torsten Bergmann" wrote: > Hi Johan, > > Still I really do not understand what particular problem that is solved by > changing > the template from > > MySuperclass subclass: #Foo > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Bar-Core' > > to > > MySuperclass subclass: #Foo > instanceVariableNames: '' > classVariableNames: '' > category: 'Bar-Core' > > other than some of your student had problem not yet knowning what pool > dictionaries are > and you want to hide pools therefore. A weak argument since some students may > not yet > know about class variables - so why not hiding them in the first place too? > > Another teacher may argue that his students got problems because the template > was changed > and nearly all ST, Seaside and Pharo books used for teaching include the > extended variant > of the message. > > IMHO a class template is (as the name says) a "template" and a template > should be > something one just has to fill out. The idea of a template is to avoid too > much typing afterwards. > So the idea is one just should fill out the template without much hazzle. > If I require an ivar, a class variable, a pool or a category I just put it in. > > By now reducing the template people who require pools have to do more typing > and > they have to remember the order of words in the keyword message... > > I stand at my point I think there is not much real value in this change of > the default > template, but are fine if community agrees on the reduced version. > > Thanks > T. > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
I don't see why there needs to be a configuration for that. You can still add them, just put pooldictionaries: 'foo bar' on the next-to-last line as it was before, et voilá … you have them in your class. This is the same behavior as traits and the uses: message. There is not configuration option present for that, AFAIK. On Jan 31, 2014, at 4:42 AM, "Torsten Bergmann" wrote: > Please make it a setting - so one can see the creation message with > poolDictionaries in Nautilus > as before in the browser and is able to fill out the template. > > When using NB one requires them. > > Thx > T. > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] poolDictionaries removal breaks my projects
The behavior that Stef explains is indeed what was intended: when they are used show them, when not, not. This is just like Traits. The implementation was broken in this respect though. Sorry for that. I have submitted a fix. https://pharo.fogbugz.com/f/cases/12752 Note that the original way in which classes are created was never adapted, only the way the classes are shown in Nautilus is different than before. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
