August 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Keyboard work flow?

by Dimitris Chloupis

That's the spirit indeed , as a Pharo dev you basically design or improve your development tools. I did not imply that we prefer using only the mouse, obviously if that was true we would not have shortcuts. If memory serves correctly Pharo already offers 217 shortcuts which is a good start (according to the keymap browser you can find in World Menu -> System -> Keymap Browser). Personally when I use GTSpotter I use only shortcuts, when I open the System Browser I use a mix of shortcuts for common actions and mouse for more specific. But yeah I rely a lot on mouse because I work very slow , shortcuts would not be beneficial in my case in terms of speed. If I was working way faster I would have probably used shortcuts a lot more but I prefer to really digest information so using the mouse never becomes an issue in terms of speed but yeah I also use a lot of shortcuts. You can find info about modifying and adding new shortcuts here https://playingwithobjects.wordpress.com/2013/03/19/keymappings-101-for-pha… One thing that Pharo misses is global shortcuts. But even without them you should be able to customize pharo image the easy way. Jump in and do your thing , then nice thing about images is that each image can have diffirent shortcuts so you can create diffirent setups if you want and do all sort of crazy stuff. Also you can always submit your extra shortcuts to be included in a future standard pharo image. I dont think you will get any big complain about it. Just open a case in pharo fogbuz as a new feature and also send a message to the mailing list so we can pay more attention to it. The nice thing about Pharo is that is a very open friendly community so you dont have to fight red tape or large committees like you would in other popular languages to get stuff included or modify pharo in some way. Being small community allows us to be far more agile on these matters. One of the reasons I love using Pharo. On Tue, 23 Aug 2016 at 21:33, Erik Peldan <erik.peldan(a)gmail.com> wrote: > Agreed, a mouse is simpler. But a keyboard is faster and (more > importantly) ergonomic. I am a bit surprised that you say probably most > Pharo devs prefer using the mouse, Dimitris. Being new to Smalltalk, my > impression was that the openness of the environment lends itself very well > to customization of this sort; context-sensitive shortcuts, custom menus > and other utilities tailor made for the specific task at hand. Do people do > this or is it preferred to not stray too far from the official releases? > > Personally, I'm fine with using whatever shortcuts are already there but I > would like to be able to add my own when they are missing. > In my opinion, most of my workflow issues would be elegantly solved if I > could sort of 'shift' keyboard focus to different subcomponents WITHIN a > single system window. For example, in the Code Browser, if I could maybe > use CTRL-1,2,3,4,5 etc to focus the package, class, category, method and > code panels respectively. This would allow me to fire up a Code Browser, > find a class, edit the source code, etc using nothing but the keyboard. > Tips on how best to implement this are appreciated :) > > 2016-08-23 13:53 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> The problem is not so much that Pharo has not shortcuts for everything, >> or that shortcuts are tricky to make or modify. The problem is that Pharo >> is a very complex environment, more complex than emacs and vim. It's very >> easy to create messy shortcut setups like emacs and vim. >> >> Saying that yes sure it's possible but I do suspect that most Pharo devs >> are like me, love shortcuts but using mouse is just simpler. Hence why >> Pharo is no emacs/vim , thank God :D >> >> But probably it will require for you to customize and create new >> shortcuts. After all emacs and vim users use their own personal shortcuts >> tailor made for their needs. >> >> On Sun, 21 Aug 2016 at 23:26, epeld <erik.peldan+squeak(a)gmail.com> wrote: >> >>> Hello! >>> >>> Is it possible to get by using ONLY the keyboard in the standard >>> development >>> components? >>> >>> Here are some workflows that I frequently use and would like to perform >>> without mouse if possible: >>> >>> 1. Use Spotter to browse a class >>> >>> 2. Define a new method. That is, allow me to immediately focus the source >>> code editor so I can start typing a new method >>> >>> or >>> >>> 1. Use Spotter to browse the implementation of a method >>> >>> 2. Edit its source code and accept >>> >>> 3. Now recategorize or rename or create new class etc etc. (the problem >>> here >>> is that the source code editor will shadow all the shortcuts I normally >>> have >>> in the browser, e.g CMD-M CMD-M would normally recategorize the method, >>> but >>> now this brings up the implementors list instead. >>> >>> Thanks! >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Keyboard-work-flow-tp4912091.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >

Aug. 23, 2016

Re: [Pharo-users] standalone/runtime executable

by kmo

<<Pharo has the easiest deployment in any language I have used.>> Only if you think deployment means shipping your entire development environment to users and telling them to get on with it. Pharo is absolutely the worst language for deployment in the world. This is why, after all these years, there have only ever been three desktop applications written in it - phratch, dr geo, and the a legal database thing. (i suppose you could be generous and include pharo launcher as well - though that's a bit incestuous). All other applications written in pharo are web apps so deployment is not an issue. There may be good reasons for the lack of attention paid to the deployment of apps but pretending there is no problem is crazy. -- View this message in context: http://forum.world.st/standalone-runtime-executable-tp4911677p4912370.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 23, 2016

Re: [Pharo-users] Keyboard work flow?

by Erik Peldan

Agreed, a mouse is simpler. But a keyboard is faster and (more importantly) ergonomic. I am a bit surprised that you say probably most Pharo devs prefer using the mouse, Dimitris. Being new to Smalltalk, my impression was that the openness of the environment lends itself very well to customization of this sort; context-sensitive shortcuts, custom menus and other utilities tailor made for the specific task at hand. Do people do this or is it preferred to not stray too far from the official releases? Personally, I'm fine with using whatever shortcuts are already there but I would like to be able to add my own when they are missing. In my opinion, most of my workflow issues would be elegantly solved if I could sort of 'shift' keyboard focus to different subcomponents WITHIN a single system window. For example, in the Code Browser, if I could maybe use CTRL-1,2,3,4,5 etc to focus the package, class, category, method and code panels respectively. This would allow me to fire up a Code Browser, find a class, edit the source code, etc using nothing but the keyboard. Tips on how best to implement this are appreciated :) 2016-08-23 13:53 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > The problem is not so much that Pharo has not shortcuts for everything, or > that shortcuts are tricky to make or modify. The problem is that Pharo is a > very complex environment, more complex than emacs and vim. It's very easy > to create messy shortcut setups like emacs and vim. > > Saying that yes sure it's possible but I do suspect that most Pharo devs > are like me, love shortcuts but using mouse is just simpler. Hence why > Pharo is no emacs/vim , thank God :D > > But probably it will require for you to customize and create new > shortcuts. After all emacs and vim users use their own personal shortcuts > tailor made for their needs. > > On Sun, 21 Aug 2016 at 23:26, epeld <erik.peldan+squeak(a)gmail.com> wrote: > >> Hello! >> >> Is it possible to get by using ONLY the keyboard in the standard >> development >> components? >> >> Here are some workflows that I frequently use and would like to perform >> without mouse if possible: >> >> 1. Use Spotter to browse a class >> >> 2. Define a new method. That is, allow me to immediately focus the source >> code editor so I can start typing a new method >> >> or >> >> 1. Use Spotter to browse the implementation of a method >> >> 2. Edit its source code and accept >> >> 3. Now recategorize or rename or create new class etc etc. (the problem >> here >> is that the source code editor will shadow all the shortcuts I normally >> have >> in the browser, e.g CMD-M CMD-M would normally recategorize the method, >> but >> now this brings up the implementors list instead. >> >> Thanks! >> >> >> >> -- >> View this message in context: http://forum.world.st/ >> Keyboard-work-flow-tp4912091.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >>

Aug. 23, 2016

Re: [Pharo-users] standalone/runtime executable

by Travis Ayres

I don't want to present a whole application environment to the user, I want to disable everything not having to do with the task at hand. Also, it gives people with more limited bandwidth connections the options of downloading the entire thing, or a highly stripped version that is much smaller. It certainly makes getting a "build environment" easy when asking for contributions though! Dolphin has a similar tool and is now open source, perhaps there is something there worth investigating for Pharo. I'll check out Phratch (also, Scat is an unfortunately named tool). On Tue, Aug 23, 2016 at 4:26 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Pharo has the easiest deployment in any language I have used. It's just a > single folder. It does not get any simpler way than that. You can also > customize the name of the executable, the icon, the folder and the image > itself. There is no need to install Pharo or your Pharo application. > > So what you are asking yes it would be good for a beginner but someone > that has some substantial experience with Pharo it's nowhere near as > necessary. > > Start experimenting you will be suprised how powerful it is. > > On Thu, 18 Aug 2016 at 11:37, Gour <gour(a)atmarama.com> wrote: > >> Hello, >> >> there are some Smalltalks like Dolphin, VisualWorks..which can, afaict, >> create stand-alone executable for easier deployment to end users. >> >> I'm aware that Pharo probably has more important tasks to tackle first, >> but just curious if creating stand-alone/runtime exectuables is >> somewhere on its radar? >> >> >> Sincerely, >> Gour >> >> -- >> As a lamp in a windless place does not waver, so the transcendentalist, >> whose mind is controlled, remains always steady in his meditation on the >> transcendent self. >> >> >> >>

Aug. 23, 2016

Re: [Pharo-users] Keyboard work flow?

by Dimitris Chloupis

The problem is not so much that Pharo has not shortcuts for everything, or that shortcuts are tricky to make or modify. The problem is that Pharo is a very complex environment, more complex than emacs and vim. It's very easy to create messy shortcut setups like emacs and vim. Saying that yes sure it's possible but I do suspect that most Pharo devs are like me, love shortcuts but using mouse is just simpler. Hence why Pharo is no emacs/vim , thank God :D But probably it will require for you to customize and create new shortcuts. After all emacs and vim users use their own personal shortcuts tailor made for their needs. On Sun, 21 Aug 2016 at 23:26, epeld <erik.peldan+squeak(a)gmail.com> wrote: > Hello! > > Is it possible to get by using ONLY the keyboard in the standard > development > components? > > Here are some workflows that I frequently use and would like to perform > without mouse if possible: > > 1. Use Spotter to browse a class > > 2. Define a new method. That is, allow me to immediately focus the source > code editor so I can start typing a new method > > or > > 1. Use Spotter to browse the implementation of a method > > 2. Edit its source code and accept > > 3. Now recategorize or rename or create new class etc etc. (the problem > here > is that the source code editor will shadow all the shortcuts I normally > have > in the browser, e.g CMD-M CMD-M would normally recategorize the method, but > now this brings up the implementors list instead. > > Thanks! > > > > -- > View this message in context: > http://forum.world.st/Keyboard-work-flow-tp4912091.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 23, 2016

Re: [Pharo-users] standalone/runtime executable

by Dimitris Chloupis

Pharo has the easiest deployment in any language I have used. It's just a single folder. It does not get any simpler way than that. You can also customize the name of the executable, the icon, the folder and the image itself. There is no need to install Pharo or your Pharo application. So what you are asking yes it would be good for a beginner but someone that has some substantial experience with Pharo it's nowhere near as necessary. Start experimenting you will be suprised how powerful it is. On Thu, 18 Aug 2016 at 11:37, Gour <gour(a)atmarama.com> wrote: > Hello, > > there are some Smalltalks like Dolphin, VisualWorks..which can, afaict, > create stand-alone executable for easier deployment to end users. > > I'm aware that Pharo probably has more important tasks to tackle first, > but just curious if creating stand-alone/runtime exectuables is > somewhere on its radar? > > > Sincerely, > Gour > > -- > As a lamp in a windless place does not waver, so the transcendentalist, > whose mind is controlled, remains always steady in his meditation on the > transcendent self. > > > >

Aug. 23, 2016

Re: [Pharo-users] Google building new OS with Dart

by Dimitris Chloupis

An area that generally interests me is making languages cooperate. When I started with the idea of Pharo using Python libraries, I thought it would take me months to have something usable. Instead it took me weeks mainly because I found that a very simple solution could provide me with a working prototype. So my project Ephestos was born and allowed me to use Pharo to script Blender via Python using sockets , strings, Python execution and some Pharo tricks. It literally blown my mind how easy and simple it was. Of course its far from ideal solution. I have managed to keep most of the Pharo syntax for converting to Python syntax but data is a whole another beast. No complains SmaCC did help a lot there to parse Python dictionaries and lists to Pharo ordered collections. However when another user emailed that he had problems using Ephestos to use the popular Python library Numpy from Pharo, it shown me that there is no such thing as universal solution. After my decision to turn my attention to game development and Unreal game engine, I started learning a lot of C++ and I am wondering what it would take to transpile Pharo code to C++. The difference here is that C++ is no Python , it has a monstrous syntax and is a compiled language. However Pharo already does this with Slang that inherited from Squeak. Slang takes Smalltalk syntax and transpiles it to C. It's mainly used for coding the Pharo VM. C of course is nowhere near as large syntax wise as C++ but at least Slang generates readable code which is my goal. So Pharo is not the isolated island that Smalltalk once was and there is no turning back. There is amber that transpiles Smalltalk to JavaScript, PharoJS that transpiles Pharo to JavaScript and JNIPort that allows Pharo to use Java libraries. So yes it's not that hard if you really want to build a transpiler for Pharo to Dart code and vice versa. On the Subject of OS , Pharo is already a virtual OS. The advantage of virtual OS over regular OS , is that a virtual OS is much simpler in design so easier to hack and play with and also has access to the entire OS it runs on. So in my case what interests me is transpiling Pharo to C++, because that's the language Unreal uses. It will be a challenge but is doable. It would be a big plus for Pharo if it had a powerful transpiler tool that would allow you to convert Pharo code to any language producing readable code. This would allow Pharo access to any project out there. However remember what I said, there are no universal solutions or magic pills. Compromises and sacrifices would have to be made but it's possible. Don't expect others to do it for you, brainstorming and talking about it is far from doing. As Stef wisely says "Pharo is yours" On Thu, 18 Aug 2016 at 07:25, askoh <askoh(a)askoh.com> wrote: > It became news a few days ago. It is called Fuchsia and is meant to run on > all devices from IoT on up. The interesting thing is that Dart will be the > main language. The developers promise to make Fuchsia run on Raspberry Pi 3 > shortly. > > Since Dart is pretty close to Smalltalk, how can Smalltalk be the GUI for > Fuchsia? How can it take advantage of Dart VM? Is this an opportunity for > Smalltalk to make an impact? Let's brainstorm. > > All the best, > Aik-Siong Koh > > > > -- > View this message in context: > http://forum.world.st/Google-building-new-OS-with-Dart-tp4911649.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 23, 2016

Re: [Pharo-users] Spec > TreeModel: Updating the tree selection after a deletion

by Offray Vladimir Luna CÃ¡rdenas

Hi Nicolai, About the rebuilding of the subwidgets, I really don't know. Maybe if I can force the highlighting I can't ignore the rebuilding issue in some way, so that's what I'm trying now and seems I'm closer. Do you know how to make a TreeNodeModel to show itself expanded? I tried with '#isExpanded: true' and still it doesn't show itself expanded. Any hint? Any Spec expert attendee in ESUG16 that can spare some minuted enlightening a newbie? Cheers, Offray On 21/08/16 18:12, Nicolai Hess wrote: > Hi Offrey, > I think one problem is that the tree is always rebuild (on every > selection?) > > even with > self needRebuild:false > tree needREbuild: false. > > all subwidgets of the notebook (tree and body) are removed and rebuild > from changeBodys call to self buildWithSpecLayout: self class > defaultSpec. > I don't know if this is a bug or unavoidable. > > > 2016-08-18 17:31 GMT+02:00 Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>>: > > Hi all, > > Thanks Nicolai. Your examples helped me to advance and now I have > the basic possibility to modify the tree. The two methods that did > the trick are #addNode and #highlightNextitem, listed below, but I > still get a MNU: receiver of "selectedMorphList is nil, anytime I > try to highlight the next item and even from time to time with > your code example. If you or anyone want to work with the code > directly please install run the playgrounds at [1], [2] & [3], > select any node after running [3] and press the Plus button. > You'll see that nodes are added in the tree after the current > selection, but the recently added node doesn't get the selection > after being created (instead the MNU mentioned before, appears). > > I will try to use the new created grafoscopio node and look for > the TreeNodeModel which has this node as a content to get the > highlight. > > Help as always is greatly appreciated. > > Cheers, > > Offray > > [1] http://ws.stfx.eu/M5A1F2NPD0QU > [2] http://ws.stfx.eu/EVOY0UKH74L0 > [3] http://ws.stfx.eu/5EF0OCUIG7CY > > ================ > > GrafoscopioNotebook>>addNode > tree needRebuild: true. > tree highlightedItem content addNodeAfterMe. > self notebookContent: notebook. > self highlightNextItem. > self buildWithSpecLayout: self class defaultSpec. > > > ================ > > GrafoscopioNotebook>>highlightNextItem > | currentItem | > currentItem := tree highlightedItem. > currentItem > ifNotNil: [ | allItems index childrenSize parentNode | > currentItem parentNode > ifNil: [ > parentNode := currentItem container. > allItems := parentNode roots ] > ifNotNil: [ > parentNode := currentItem parentNode. > allItems := parentNode children value. ]. > childrenSize := currentItem content parent children size. > index := allItems indexOf: currentItem. > (index < childrenSize) ifTrue: [ > "{allItems . currentItem . index } inspect." > currentItem selected: false. > parentNode > highlightedItem: ((allItems at:(index+1)) > selected:true; > takeHighlight;yourself). > ] > ] > > > > On 11/08/16 13:05, Nicolai Hess wrote: >> >> >> 2016-08-10 21:03 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com >> <mailto:nicolaihess@gmail.com>>: >> >> >> >> 2016-08-10 20:42 GMT+02:00 Nicolai Hess >> <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: >> >> >> >> 2016-08-10 19:12 GMT+02:00 Nicolai Hess >> <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: >> >> >> >> 2016-08-10 19:05 GMT+02:00 Offray Vladimir Luna >> CÃ¡rdenas <offray.luna(a)mutabit.com >> <mailto:offray.luna@mutabit.com>>: >> >> Hi, >> >> I have been fighting with this for several hours >> until now. I can't understand how to manage >> change on selections on TreeModels with Spec, >> which is really frustrating.... >> >> Here is what I have: >> >> GrafoscopioNotebook>>initializePresenter >> tree whenSelectedItemChanged: [ :item | >> self updateBodyFor: item. >> header whenTextChanged: [ :arg | >> (tree selectedItem content header) = arg >> ifFalse: [ >> (tree highlightedItem) content header: arg. >> tree roots: tree roots]]] >> >> GrafoscopioNotebook>>updateBodyFor: item >> item >> ifNotNil: [ self changeBody: item ] >> ifNil: [ self inform: 'Nil node' ] >> >> and #changeBody: deals with putting a textual or >> code pane according to some tags on the selected >> node (and it's working properly). >> >> The problem seems that when I add/delete nodes to >> my tree, or while changing the selection between >> nodes, the item variable becomes temporarily nil >> and I can't update the contents of the body to >> correspond to the current selection. I would like >> to say explicitly that a new tree added node gets >> the selection and that the deletion of nodes >> gives selection to its siblings or parent (if >> there are not siblings) and that node body pane >> should be updated accordingly. >> >> Again, any hint would be really valuable... I'll >> take a break from the computer to dissipate >> current frustration... Pharo is generally a happy >> productive place... but not today :-/... anyway >> some hits are part of learning to play with it. >> >> >> Hi Offray, >> I do remember that I tried this as well, I will if I >> can find out how far I got it to work. >> >> >> a simiple example: >> >> |t nodeBlock | >> nodeBlock:= [:class | |node| >> node := TreeNodeModel new. >> node hasChildren:[ class subclasses isEmpty not]. >> node children: [class subclasses collect:[:subclass | >> nodeBlock value: subclass]]. >> node content: class]. >> t:=TreeModel new. >> t roots: (Morph subclasses collect:[:class | nodeBlock >> value:class]). >> t whenBuiltDo:[ t selectedItem:( t roots first >> selected:true;takeHighlight;yourself)]. >> t openWithSpec >> >> the important part is the "takeHighlight" and to call it >> after the widget is built >> >> >> >> And an awfull example on how to modify selection (only the >> nodes of the root, couldn't find out how to do it for >> arbitrary subnodes) >> >> |t nodeBlock | >> nodeBlock:= [:class | |node| >> node := TreeNodeModel new. >> node hasChildren:[ class subclasses isEmpty not]. >> node children: [class subclasses collect:[:subclass | >> nodeBlock value: subclass]]. >> node content: class]. >> t:=TreeModel new. >> t autoDeselection:true. >> t roots: (Morph subclasses collect:[:class | nodeBlock >> value:class]). >> t menu:[:menu ||group| >> group := MenuGroupModel new. >> menu addMenuGroup: group. >> group addMenuItem:(MenuItemModel new name:'next';action:[ >> |item| >> item := t selectedItem. >> item ifNotNil:[|allItems index| >> allItems := item container roots. >> index := allItems indexOf: item. >> (index < allItems size) ifTrue:[item >> selected:false. item container selectedItem:((allItems >> at:(index+1)) selected:true;takeHighlight;yourself)] >> ] >> ])]. >> t whenBuiltDo:[ t selectedItem:( t roots first >> selected:true;takeHighlight;yourself)]. >> t openWithSpec >> >> again, the important part is #selectedItem: and >> #takeHighlight, otherwise the model doesn't know about the >> selection change. >> >> >> >> Hm, yes, updating the selection after deletion is much more >> difficult. The problem is that most in spec TreeModel is done for >> creating the tree widget, not >> for managing nodes and changes afterwards. >> >> >> Cheers, >> >> Offray >> >> >> On 07/08/16 16:11, Offray Vladimir Luna CÃ¡rdenas >> wrote: >> >> Hi, >> >> I have a Spec TreeModel to represent the GUI >> of a grafoscopio notebook. >> >> The message that deletes nodes is something >> like this: >> >> ============ >> >> GrafoscopioNotebook>>removeNode >> | nodeToDelete | >> nodeToDelete := tree selectedItem content. >> nodeToDelete parent removeNode: nodeToDelete. >> tree selectedItem: tree selectedItem >> parentNode. >> tree needRebuild: true. >> tree roots: tree roots. >> self buildWithSpecLayout: self class >> defaultSpec. >> >> ============= >> >> And its working fine in the sense that it >> deletes the selected node, but after the >> deletion the contents of the old node are >> showed no matter if I change the node >> selection on the tree. I would like to manage >> selections in a smart way, so if I add a new >> node to the notebook, the new node gets the >> selection. If I delete a notebook node, the >> previous node gets selected or the parent if >> no more siblings are encountered and so on. >> There is some simple example to look for, >> about managing and updating selections in a >> TreeModel interface? >> >> Thanks, >> >> Offray >> >> >> >> >> >> >> >> >> > >

Aug. 23, 2016

Re: [Pharo-users] Pharo 5 and image resizing

by Nicolas Passerini

On Fri, Aug 19, 2016 at 10:04 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I've a concern with the image resizing in Pharo 5, as when I'll be loading > several (tons of) packages, MCZs will be piling up and if clearing that > cache isn't going to reduce the size of the image, I am not really keen on > dragging these around. This will just get worse over the course of the > development. > > The image-not-shrinking problem will be solved in the near future, I think that it shouldn't be a big worry if you are starting a new project.

Aug. 23, 2016

Re: [Pharo-users] Pillar question: PRCitationTransformer

by Yann Dubois

Hi stef, You can not have a citation annotation on a writer because the annotation is transformed before to a PRCitation object. So you need to overwrite visitCitation. PRCitationTransformer is called in the phase mechanism. He is added in the transform pipeline. PRCitationTransformer will be rename to PRCitationAnnotationTransformer because this class change the citation annotations and not the citations. Le 22 aoÃ»t 2016 07:36, "stepharo" <stepharo(a)free.fr> a Ã©crit : Hi I'm trying to extend Pillar to get new $publications:...$ structure and it looks like Pillar is getting more and more complex. And the comments do not really help because they are short and written for someone already understanding it. :( To try to understand I tried to ! Youpi ${cite:ref=Duca18rmod}$ !! Others but I get {"content":"!Youpi\n\n\n\n!!Others"} ./pillar export --to=pillar Example.pillar May be I cannot export to pillar a citation. I have no idea. I tried to add PRPillarWriter >> visitCitationAnnotation: aCitation "We invoke visitAnnotation: to make sure that the rest of the document is visited." self halt. super visitCitationAnnotation: aCitation Did not stop! So I put an halt into PRVisitor >> visitCitationAnnotation: aCitationAnnotation self halt. self createNewCitationWith: aCitationAnnotation. self replace: (OrderedCollection with: tmpCitation) . super visitCitationAnnotation: aCitationAnnotation and it stopped. I tried to understand who is calling PRCitationTransformer No luck. I'm sure that there is a magic registration mechanism but I failed to find it. Looking at tests (BTW Tests are not documentation or class comments, there are tests). It looks like I need a configuration. (self actualClass executeOn: (PRCompilationContext withDocument: anInput withConfiguration: aConfig)) input And then I fall on executeOn: implementors..... LLPhase and PRNodeTransformer. and I have no idea how a Phase relates to a visitor. To bad, after all the efforts on Pillar it looks like getting too complex. So do not think that we can decently ask students to work on improving Pillar anymore because they will just get lost and disgusted from Pharo. :( Sad news isn't. I hope that I will not have to switch back to LaTeX or markdown (shit). Stef

Aug. 22, 2016