- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] new website about Artefact

by camille teruel

Congrats it's very funny :D 2014-03-24 15:40 GMT+01:00 olivier <olivier.auverlot(a)gmail.com>: > Hi, > > A website is now available about Artefact. Documentation and useful > informations are grouped to help you to produce many and beautiful PDF > documents with Pharo. > > https://sites.google.com/site/artefactpdf/ > > The pasta team >

March 24, 2014

Re: [Pharo-dev] new website about Artefact

by Sergi Reyner

2014-03-24 14:40 GMT+00:00 olivier <olivier.auverlot(a)gmail.com>: > Hi, > > A website is now available about Artefact. Documentation and useful > informations are grouped to help you to produce many and beautiful PDF > documents with Pharo. > > https://sites.google.com/site/artefactpdf/ I am of the opinion that any documentation that includes unicorns is an automatic +1. So, +2! Cheers, Sergi

March 24, 2014

new website about Artefact

by olivier

Hi, A website is now available about Artefact. Documentation and useful informations are grouped to help you to produce many and beautiful PDF documents with Pharo. https://sites.google.com/site/artefactpdf/ The pasta team

March 24, 2014

Created PetitParserExtension project

by Guillaume Larcheveque

Hi everybody, I am using PetitParser a lot and had implemented some little tools that help me for writing or generating grammars. I put two of the most useful in the project PetitParserExtension ( http://smalltalkhub.com/#!/~Moose/PetitParserExtensions) the first one is useful when you generate grammars with lots of rules: A PPExtendedCompositeParser offers you a new way to create rules. Just define your rule as a method in the #rules protocol and it will be managed exactly like rules in PPCompositeParser. You will not have the limitation of 256 rules due to the instance variables limit but you will need to refer to your rule with the method #rule: in any other rule using it. You can mix PPCompositeParser and PPExtendedCompositeParser way to define rules. the second one is cool for token identification because it creates a parser that will parse in a time depending on token length and not the number of different tokens. A PPMultiStringParser is a tool able to create a really effective parser on a huge collection of Strings. This parser will match any string in this collection, and the longest one if two are matchable (( PPMultiStringParser on: #('tin' 'tintin')) parse: 'tintin' will match 'tintin' and not just 'tin') If someone else has implemented some tools around PetitParser, it will be great to put those all together so feel free to commit your tools in this project and to improve mines. -- *Guillaume Larcheveque*

March 24, 2014

Re: [Pharo-dev] Debugger acting up

by Gary Chambers

Hi, maybe related to something I found when using our locked-down images (no Tools in ToolRegistry). In SmalltalkImage>>openLog FileStream fileNamed: Smalltalk tools debugger logFileName was causing a loop since the default error handling ends up sending #logDuring:, which sends #openLog, causing an attempt to log an error (no debugger)... For a quick workaround I changed to openLog "This is a _private_ method, Because it really belongs to logging facility, we should delegate to it at some point " ^ ( FileStream fileNamed: Debugger logFileName ) wantsLineEndConversion: true; setToEnd; yourself though obviously not ideal having the direct reference to Debugger there. Regards, Gary ----- Original Message ----- From: "Diego Lont" <diego.lont(a)delware.nl> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> Sent: Friday, March 21, 2014 2:32 PM Subject: [Pharo-dev] Debugger acting up Hi all, I do not have a proper test case yet, but as I have seen it twice now I want to ask you guys if you have any problems with it. In a recent moose 5.0 image with seaside and some other suff loaded, the page would not load. Interrupting the image showed that the debugger was lost in the following loop: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: Originally it was a halt that caused the signal, and that should pop up the debugger, but instead of that it went into an infinite loop. Now I see that building Pier3 development on a pharo2 image also seems to causes this loop. The root cause is also in the mail, so maybe this is just the size of the stack ...: Startup Error: An attempt to use interactive tools detected, while in non-interactive mode Interactive Request: You are about to load new versions of the following packages that have unsaved changes in the image: Grease-Tests-Pharo20-Core If you continue, you will lose these changes: [0mNonInteractiveUIManager>>nonInteractiveWarning: NonInteractiveUIManager>>nonInteractiveRequest:title: NonInteractiveUIManager>>nonInteractiveRequest: NonInteractiveUIManager>>confirm:trueChoice:falseChoice:cancelChoice:default: MCMergeOrLoadWarning>>defaultAction UndefinedObject>>handleSignal: If anyone knows where this problem might come from, please put a mail on the mailing list. Cheers, Diego

March 24, 2014

Re: [Pharo-dev] FileSystemGit and Fuel final report

by Max Leske

On 24.03.2014, at 11:08, Stephan Eggermont <stephan(a)stack.nl> wrote: > Great! > > I have a different (and lower priority) use case for the libgit2 bindings: > Michael Feathers has done some history analysis on github repositories > which weâve used at the SPA2011 egg race. Basically, commit info on > method level for 4 ruby projects. I guess Iâd have to use the low level > bindings to do similar things? Not necessarily. The API could expose `git log` operations and then you could easily get a list of all commits referencing a specific method (for instance). If you want to do that yourself of course, then yes, youâll have to use the bindings (or rather the minimal objectified abstraction. Using the bindings directly is kind of dangerous). In my opinion however, Git provides all the tools you need for that and you should use those tools if possible. Does that answer your question? Bug me again if not :) Max > > Stephan

March 24, 2014

Re: [Pharo-dev] StHub Support Ticket

by Nicolas Petton

Sven Van Caekenberghe writes: > Can someone please help Philippe Marschall who is having trouble saving to StHub ? His account is http://www.smalltalkhub.com/#!/~marschall > > He seems to be able to log in to the website part, but can't save > anything. Not in the Seaside repositories, nor in a new Test > repository that he just created. He was able to work normally until > very recently (february). Hi! Yes, Philippe sent me an MCZ file, and I'm doing some testing. Cheers, Nico > > TIA, > > Sven -- Nicolas Petton http://nicolas-petton.fr

March 24, 2014

Re: [Pharo-dev] FileSystemGit and Fuel final report

by Sven Van Caekenberghe

Sounds like a productive week ! Thanks for the report and the work. On 24 Mar 2014, at 10:06, Max Leske <maxleske(a)gmail.com> wrote: > For those whoâve been interested in what went on during the last two weeks, where I visited Lille, Iâve compiled a short report. Regarding my work on Git Iâll continue to report on the status from time to time. > > I want to thank everyone at RMoD once again for the warm welcome and the support I received. Special thanks to Ben and Camillo for providing a place to crash at. > Thanks also go to all of you guys and girls on the list for pushing Pharo constantly and for showing interest in my work. Itâs very encouraging. > > Cheers, > Max > > > Git: > - Esteban Lorenzano and me worked together on preparing the libgit2 and libssh2 libraries for integration into the VM > - Igor Stasenko worked with me to solve a couple of problems I had with NativeBoost. Especially callbacks can be tricky > - Learnt how to build the VM in debugging mode so that I could debug FFI calls in XCode > - Stefan Marr worked with me on moving the tests from Phexample to SUnit > - The implementation now enables writing of blobs, trees and commits, cloning of remote repositories (https), fetching from remote repositories (https), pushing to remote repositories (https) > - Authentication with remote repositories via SSH is working but clone, fetch, push don't work yet (problems with the libssh2 interaction that I wasn't able to resolve yet) > - I set up an initial build infrastructure on the INRIA CI server (https://ci.inria.fr/pharo-contribution/job/LibGit2/) > - We defined a rough roadmap for what needs to be done in the near future: > 1. finish the low level libgit2 abstraction (offer a minimal API that hides the bindings; we don't want users to use the bindings directly) > 2. we already have a prototype of a FileSystem wrapper for Git. We want to use that on top of the libgit2 abstraction layer > 3. we already have a Monticello FileSystem wrapper prototype. We want to use that to abstract from the actual storage method. Together with the Git-FileSystem wrapper this should make it very easy to continue (for now) using Monticello and the existing GUI tools while using Git as a backend for storage. > - On Friday 21 I gave a short demo at RMoD on the work accomplished and what the plans are for the future > > Fuel: > - MartÃn Dias and I worked together on: > - debugging a problem with large object graphs > - preparing a new baseline for Fuel 2 > - moving the benchmark suite to SMark > - setting up a benchmark build on the INRIA CI server which will help us track performance changes when introducing changes > - defining a rough roadmap for Fuel > - Had a discussion with Usman Bhatti about the uses and the future of Fuel in Moose

March 24, 2014

Re: [Pharo-dev] FileSystemGit and Fuel final report

by Stephan Eggermont

Great! I have a different (and lower priority) use case for the libgit2 bindings: Michael Feathers has done some history analysis on github repositories which weâve used at the SPA2011 egg race. Basically, commit info on method level for 4 ruby projects. I guess Iâd have to use the low level bindings to do similar things? Stephan

March 24, 2014

FileSystemGit and Fuel final report

by Max Leske

For those whoâve been interested in what went on during the last two weeks, where I visited Lille, Iâve compiled a short report. Regarding my work on Git Iâll continue to report on the status from time to time. I want to thank everyone at RMoD once again for the warm welcome and the support I received. Special thanks to Ben and Camillo for providing a place to crash at. Thanks also go to all of you guys and girls on the list for pushing Pharo constantly and for showing interest in my work. Itâs very encouraging. Cheers, Max Git: - Esteban Lorenzano and me worked together on preparing the libgit2 and libssh2 libraries for integration into the VM - Igor Stasenko worked with me to solve a couple of problems I had with NativeBoost. Especially callbacks can be tricky - Learnt how to build the VM in debugging mode so that I could debug FFI calls in XCode - Stefan Marr worked with me on moving the tests from Phexample to SUnit - The implementation now enables writing of blobs, trees and commits, cloning of remote repositories (https), fetching from remote repositories (https), pushing to remote repositories (https) - Authentication with remote repositories via SSH is working but clone, fetch, push don't work yet (problems with the libssh2 interaction that I wasn't able to resolve yet) - I set up an initial build infrastructure on the INRIA CI server (https://ci.inria.fr/pharo-contribution/job/LibGit2/) - We defined a rough roadmap for what needs to be done in the near future: 1. finish the low level libgit2 abstraction (offer a minimal API that hides the bindings; we don't want users to use the bindings directly) 2. we already have a prototype of a FileSystem wrapper for Git. We want to use that on top of the libgit2 abstraction layer 3. we already have a Monticello FileSystem wrapper prototype. We want to use that to abstract from the actual storage method. Together with the Git-FileSystem wrapper this should make it very easy to continue (for now) using Monticello and the existing GUI tools while using Git as a backend for storage. - On Friday 21 I gave a short demo at RMoD on the work accomplished and what the plans are for the future Fuel: - MartÃn Dias and I worked together on: - debugging a problem with large object graphs - preparing a new baseline for Fuel 2 - moving the benchmark suite to SMark - setting up a benchmark build on the INRIA CI server which will help us track performance changes when introducing changes - defining a rough roadmap for Fuel - Had a discussion with Usman Bhatti about the uses and the future of Fuel in Moose

March 24, 2014