- Pharo-users - lists.pharo.org

Pillar annotations for Latex

by Ben Coman

The Pillar documentation [1] says... "An annotated paragraph starts a line with @@ followed by either todo or note. For example, @@note this is a note annotation. generates Note: this is a note annotation. And, @@todo this is a todo annotation generates a todo annotation that is not visible in the output." However this does not work when rendering to LaTex. * The notes do not start with "Note:" * The todos are visible This seemed to be handled by... PRMarkdownWriter>>visitAnnotatedParagraph: anAnnotatedParagraph "Pier seams to lack consistensy here ..." needsABreak ifTrue: [ canvas addInvisibleSeparator ]. anAnnotatedParagraph annotation asLowercase = 'todo' ifTrue: [ ^ self visitCommentedLine: anAnnotatedParagraph ]. self nest: [ :brush | brush name: '' with: [ :nestedStream | self writeRawDuring: [ nestedStream << 'Note: '. nestedStream << anAnnotatedParagraph text trimBoth ] ] ]. needsABreak := true. but that there is no equivalent PRLaTexWriter>>visitAnnotatedParagraph: and the following is used by default... PRVisitor>>visitAnnotatedParagraph: aDocument self visitParagraph: aDocument In seeking to fix this for LaTex I found... * /needsABreak/ is an ivar of PRMarkdown and I guess not applicable to LaTex * #nest: and the /nest/ ivar it references belong to PRMarkdown, and I'm not sure of their purpose. So I cut those out, which left the following... PRLaTexWriter>>visitAnnotatedParagraph anAnnotatedParagraph annotation asLowercase = 'todo' ifTrue: [ ^ self visitCommentedLine: anAnnotatedParagraph ]. self writeRawDuring: [ nestedStream << 'Note: '. nestedStream << anAnnotatedParagraph text trimBoth ]. ...which works well enough for the usage I see so far in PharoLaserGameTutorial. [2] Now is there any important function missing, or is there a better way to do this? I also want add an annotation type, which I'll describe in a following post. cheers -ben [1] https://github.com/pillar-markup/pillar-documentation [2] https://github.com/bencoman/PharoLaserGameTutorial

May 22, 2014

Re: [Pharo-users] Ghost Proxy

by Camille Teruel

On 22 mai 2014, at 11:54, stepharo <stepharo(a)free.fr> wrote: > >> In general, we should think about if is would make sense that the language comes with >> a good proxy model by default. > > + 1 > We should do that with Camille. Yes. Now the problem is to agree on what is a "good model". There is many use cases for proxies and they come with their own models and problems. Here are some requirements I can think of: - Uniformity: all objects can be wrapped, even special ones (it's a technicality but it's still important) - Interception of all message: currently we cannot intercept #== and optimized control-flow messages like #ifTrue:ifFalse #to:do:, #whileTrue:, etc... - Encapsulation (a.k.a the self problem): avoid leaking of references to the target. E.g. "aProxy yourself" should return the proxy not the target. - Behavioral intercession: Not everything is a message send. What other events do we want to intercept? IV access is a must-have for me. - Composition: Wrapping a proxy with another one should work as expected, i.e. applying both policies in order. - Performances: intercepting message sends is slow, intercepting iv accesses is even worse (relying on code instrumentation). We would need VM support. - Security: It shouldn't be possible to by-pass or corrupt a proxy policy. - Delimited replacement: Ensure that a proxy is always used in place of its target throughout the processing of a message send, no matter the alias used (that is not necessarily "self"). Think about a read-only proxy for example. Right now, to intercept messages we have to rely on #cannotInterpret: hack. To intercept iv access or other events we have to rely on code instrumentation and delegation. It would be easier if the VM would allow to create an object that controls its own interpretation (via a metaobject that defines a MOP for example). Such an object should at least be able to specify its message lookup and how to reads and writes IVs. And optionally: - how it sends messages - how it resolves other variables (temporaries, arguments, globals, class variables) - how it resolves literals - how it executes primitives (because else the VM may cry) - how it is assigned to a variable or passed in a message (to control static/dynamic aliasing respectively) - ... many others ... With such objects (+ operating by delegation instead of forwarding) we can solve most of the requirements listed above (well except performant delimited replacement). All that to say that it is not easy... >> (this way we would avoid that everyone creates one that is not completely working) > >

May 22, 2014

Re: [Pharo-users] Versionner: Specifying un-configured packages as dependencies

by Sean P. DeNigris

jfabry wrote > I put a high priority on the simplicity rule It's good to know the dangers, but for single packages with no dependencies, I often just add it to my project. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Versionner-Specifying-un-configured-packages-as-depen… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 22, 2014

3D with Pharo and OpenGL ?

by RIOU Judith

Hy, I'm working at Thales for a year internship and I would like to do some OpenGL demos in smalltalk. I'm searching a demo which shows the capacity to implement 3D drawing with Pharo. Does a demo already available on Pharo 3.0 ? I aim to code my own demo and for example begin with a 3D drawing of the earth (earth texture and arcball camera). Thanks. Judith [@@ THALES GROUP INTERNAL @@]

May 22, 2014

Re: [Pharo-users] Versionner: Specifying un-configured packages as dependencies

by Johan Fabry

On May 22, 2014, at 5:00 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >> In general I am not so sure that adding configurations for one simple package are the way to go though. It seems like adding extra layers of indirection for reasons that are unclear to me. > > The reason is that any package* should be self described. Your configuration describes your project. If you use another piece of software, it should also be self-described. > Let's take the following example: > â¢ for now, it's easy for you to add a direct dependency to Roassal2Spec, just as if it was a part of your project ... => no problem > â¢ ... but it is not. Maybe tomorrow, Alex will need to add a dependency to one or more packages for Roassal2Spec => you will have problems because you will not get these dependencies. Of course, you can still add them to your configuration but you can easily see that you will end with a configuration including all flatten dependencies, and with a lot of dependencies not directly related to your project (transitive dependencies). Flatten dependencies is really something that we should avoid, else maintenance of dependencies will be a hell. > That's why I'm really in favor of having configurations, even for one single MC package inside the configuration. I understand what you are saying, but my point of view is different. I put a high priority on the simplicity rule: if it is just one package with no special dependencies the Monticello package is the simplest solution, so you use that. If there are special dependencies, then the simplest solution for that package to work is to have a configuration for it, so you create it. The latter is still not so obvious apparently, Alex has tried 2 times to include Roassal2Spec in the Roassal config, and it still does not load in a default Pharo 3. Alex, can you try again? ( hint hint :-) ) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

May 22, 2014

Re: [Pharo-users] Ghost Proxy

by stepharo

We will discuss. Stef > > 2014-05-21 8:37 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>>: > > In general, we should think about if is would make sense that the > language comes with > a good proxy model by default. > (this way we would avoid that everyone creates one that is not > completely working) > > > I completely agree with that. > I think that most people come back to DNU because it is there and > simple to implement. > > But some others also told me that they use a different design from the > one of Ghost and I do not know what they change and why. > > Luc > > > > On 21 May 2014, at 08:31, Luc Fabresse <luc.fabresse(a)gmail.com > <mailto:luc.fabresse@gmail.com>> wrote: > >> Hi FranÃ§ois, >> >> The code is here http://ss3.gemstone.com/ss/Ghost.html/Latest >> the configuration is working but I do not remember if I tested in >> Pharo 3 now >> >> Cheers, >> >> #Luc >> >> >> 2014-05-20 18:15 GMT+02:00 FranÃ§ois Stephany >> <tulipe.moutarde(a)gmail.com <mailto:tulipe.moutarde@gmail.com>>: >> >> What is the best way to load Ghost in Pharo 3.0? Is there a >> configuration somewhere? >> >> Is anyone using it? Voyage does seem to use the >> ProtoObject+dnu+becomeForward trick. Is there any reason for >> that? >> >> > >

May 22, 2014

Re: [Pharo-users] Ghost Proxy

by stepharo

> In general, we should think about if is would make sense that the > language comes with > a good proxy model by default. + 1 We should do that with Camille. > (this way we would avoid that everyone creates one that is not > completely working)

May 22, 2014

Re: [Pharo-users] Versionner: Specifying un-configured packages as dependencies

by Christophe Demarey

Le 22 mai 2014 Ã 01:02, Johan Fabry a Ã©crit : > > On May 21, 2014, at 5:07 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > >> To me, it is preferable to add a configuration (even if very small) for each dependency outside your project. It is the way it should be done (that's why Versionner only allows that) but they are always other ways or workarounds. > > Thanks for the answers, my trick now was to ask Alex to include the required package inside the configuration of Roassal. :-) > > In general I am not so sure that adding configurations for one simple package are the way to go though. It seems like adding extra layers of indirection for reasons that are unclear to me. The reason is that any package* should be self described. Your configuration describes your project. If you use another piece of software, it should also be self-described. Let's take the following example: for now, it's easy for you to add a direct dependency to Roassal2Spec, just as if it was a part of your project ... => no problem ... but it is not. Maybe tomorrow, Alex will need to add a dependency to one or more packages for Roassal2Spec => you will have problems because you will not get these dependencies. Of course, you can still add them to your configuration but you can easily see that you will end with a configuration including all flatten dependencies, and with a lot of dependencies not directly related to your project (transitive dependencies). Flatten dependencies is really something that we should avoid, else maintenance of dependencies will be a hell. That's why I'm really in favor of having configurations, even for one single MC package inside the configuration. * I mean, not a Monticello package but a piece of software that you want to deliver independently. It may be a whole project or part of it. It may also refers to one or many Monticello packages

May 22, 2014

Re: [Pharo-users] Versionner: Specifying un-configured packages as dependencies

by Johan Fabry

On May 21, 2014, at 5:07 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Le 20 mai 2014 Ã 22:53, Sean P. DeNigris a Ã©crit : > >> Christophe Demarey wrote >>> but it will not work as it is hosted on another repository >> >> Not that I'm recommending it, but if necessary, you could always copy it >> into your project's repo to get around that (or I think you can specify a >> repository in the #with: block of the package spec. > > To me, it is preferable to add a configuration (even if very small) for each dependency outside your project. It is the way it should be done (that's why Versionner only allows that) but they are always other ways or workarounds. Thanks for the answers, my trick now was to ask Alex to include the required package inside the configuration of Roassal. :-) In general I am not so sure that adding configurations for one simple package are the way to go though. It seems like adding extra layers of indirection for reasons that are unclear to me. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

May 21, 2014

Re: [Pharo-users] A possible problem coming from Zinc?

by Sven Van Caekenberghe

Hi Usman, Thanks for the feedback, there must be something wrong with ZnFileLogger then I guess. I'll put it on the todo list ;-) Sven

May 21, 2014