- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] extract data from .mcz

by jannik laval

Hi Alex, In 2011, I did an extractor for Monticello and Metacello configuration. It was for another model than Moose. I reused and improve your extractor. It can help you: MCHttpRepository location: 'http://www.squeaksource.com/VPraxisExporter' user: 'jm' password: '' Cheers, Jannik 2014-10-07 23:21 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Thanks! It helps! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Oct 6, 2014, at 1:47 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Alexandre, > > On Mon, Oct 6, 2014 at 9:34 AM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >> Thanks Eliot. I know this. I meant code snippet to programmatically, >> within Pharo, do some queries. >> > > Such as? > > >> Some times ago I worked on a MCZ importer in Moose. I will have a look at >> it. >> > > The key is to ask a repository for the versions it has, get one or more > versions, and create snapshots from these versions: > > > e.g. SpurBootstrapMonticelloPackagePatcher in VMMaker.oscog creates > patched versions of packages. To create a repository, e.g. > > MCRepositoryGroup default repositories > detect: [:r| r description = url] > ifNone: [MCHttpRepository > location: url > user: 'squeak' > password: 'squeak'] > > but there's also the package cache: > > MCCacheRepository default > > You can ask them what versions they have: > > repository versionNamesForPackageNamed: package name > > You can create these versions, and store them: > > (trunk possiblyNewerVersionsOfAnyOf: latestUnbranched) do: > [:unpatched| > dest storeVersion: (trunk versionNamed: unpatched)] > > And you can create "snapshots" of these versions which contain all the > definitions: > > version: version withPatches: patches for: package > | snapshot ancestry | > snapshot := MCPatcher > apply: (self patchForPackage: package withPatches: patches snapshot: > version snapshot) > to: version snapshot. > ancestry := MCWorkingAncestry new addAncestor: version info. > ^MCVersion > package: version package > info: (ancestry > infoWithName: (self spurBranchNameForInfo: version info package: package) > message: version info name, > ' patched for Spur by ', > (CCodeGenerator shortMonticelloDescriptionForClass: self class), > '\\' withCRs, > version info message) > snapshot: snapshot > dependencies: {} "punt on computing dependencies; there are't any so far" > > > HTH > > Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> On Oct 6, 2014, at 1:25 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> >> Hi Alexandre, >> >> .mcz's are just zip files. The attached extracts the .st file as the >> package name with a .st extension instead of a .mcz extension. >> >> HTH >> >> On Mon, Oct 6, 2014 at 6:49 AM, Alexandre Bergel <alexandre.bergel(a)me.com >> > wrote: >> >>> Hi! >>> >>> Anyone has some code snippet to extract data from .mcz file ? >>> Getting all the classes, doing some queries... >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> >> >> -- >> best, >> Eliot >> <mzex> >> >> -- > best, > Eliot > > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/

Oct. 8, 2014

Re: [Pharo-dev] ANNC: QR Code (v.2)

by Olivier Auverlot

Le 7 oct. 2014 Ã 13:54, J.F. Rick a Ã©crit : > Well, the QRCode natively just has a bitmap form. The little server app requests that form (perhaps with a border, mirrored, reversed, etc.) and then magnifies it and converts it to a PNG. So, putting the result in a PDF is as trivial or as hard as putting a bitmap form into a PDF. How difficult that is is something that Olivier can perhaps answer. In fact, the faster approach is to convert the PNG to a JPEG picture with Pharo and to include it into a PDF Document with Artefact. It's easy to do but I can't estimate the quality lost of the picture (I suppose that's is important for the scanning of the QRCode with a phone). pharoByExampleLogo := (ZnClient new url: 'http://pharobyexample.org/pictures/pbe-title.jpg'; get). aPage := PDFPage new. aPage add: (PDFJpegElement from: 5 mm@0mm wh: 160mm@90mm fromStream: pharoByExampleLogo readStream). The best solution is to create a QRCodeComponent in Artefact and draw the QRCode directly in the PDF document. Olivier ;-)

Oct. 8, 2014

Re: [Pharo-dev] Assigning to Block and Method arguments

by Marcus Denker

> On 07 Oct 2014, at 21:42, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > If I evaluate: (CodeImporter evaluateFileNamed: 'foo.st') > > In a headless pharo image, does it count as interactive? > Normally notâ¦ it should be non-interactive in all cases. (like loading monticello, loading change setsâ¦) Marcus

Oct. 8, 2014

Re: [Pharo-dev] FOSDEM > Looks like there is a Smalltalk room :)

by Tudor Girba

Thanks. Doru On Tue, Oct 7, 2014 at 10:50 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Yes, I'll put the CFP out soon. > > Stephan > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 8, 2014

Re: [Pharo-dev] Program visualisation

by Florin Mateoc

Hi again, On 10/7/2014 2:42 PM, Thierry Goubier wrote: > Hi Florin, > > I've changed the header for our discussion :) > good idea :) > Le 07/10/2014 05:29, Florin Mateoc a Ã©crit : >> Hi Thierry, >> >> >> Thanks for pointing it out. It is indeed interesting, but not what I >> had in mind. I am not talking about debugging here so much. I am >> quite good at that, and I find it natural to build tools that help me >> do it (and of course, Smalltalk debuggers are very good already >> (restarting a method/block pretty much gives you the benefits of >> stepping backwards)), but debugging broken behavior is more about >> mapping an internalized model of the execution with what's really >> happening, seeing where they diverge. You are just checking that what >> you think you know is true. Of course, when you find out it's not, >> you gain insight/experience. But what to do when there is nothing to >> check? What if, like in the situation you mentioned, the algorithm is >> already working (so it's producing the correct/expected results)? But >> you still want to make it better.... > > First, when dealing with complex algorithms, a restart a method/a block does not match what a full trace allows, first > because you may have side-effects (which defeats the restarting thing), second because you don't have to set the next > halt point when you go backward and restart, third because the debugger may lock your environment (think about halting > one of the Rectangle methods, for example). However, you may loose some of the context in the trace. > I was only comparing a debugger with restart capabilities to a debugger that can step backwards. Side-effects are equally bad for stepping backwards (you cannot unsend that tcp-ip packet nor make the native UI retract its actions). To debug side-effects (or UI in particular) specialized (unfortunately mostly ad-hoc, sometimes bug-specific (such as UI locking, UI resource leaks) tools need to be created anyway. > Second, your last statement is self-defeating: you want to make your algorithm better, which means you have the > knowledge of what makes it tick and improve. I describe that process as moving in the design space of the algorithm, > and that great tools are the ones which help you find the right direction in that design space. I don't understand the self-defeating part. Indeed, I do start with some knowledge, and because of that, initially I can come up with some external representation, which reflects that understanding. After staring at it enough (in its dynamic behavior), I can notice ways to improve things. I "milk" the representation until the initial behavior is barely recognizable. At that point it is not helpful anymore. I need a different representation now to stare at, since I have the nagging feeling that I am still leaving something on the table. How do I get to the next one? Moving in the design space sounds exactly right. So, how do you do that? What I want help with is what I am not as good at. I want to >> literally "see" what's wrong (not good enough) with the picture, >> since the brain has those very powerful visual pattern matching >> capabilities. They remain unused when you are lost in the minutiae of >> the debugger, where you only see text and numbers, the >> granularity/level of abstraction is too low. Profilers are a little >> better - they also succinctly capture the execution tree, and I have >> also used traces for hard to debug sequences. > > The brain has some good abilities, but they are not what I'd call pattern matching (or at least you need to be very > carefull with which visual variable you want to exploit: some are not suited at all to that type of visual analysis). > I refer to SÃ©miologie Graphique, J. Bertin, for that. > > What I have considered in the work I did in the past on that is that visual systems have natural abstraction > capabilities if we use / exploit them, and that they avoid the problems associated with building a formal abstraction > process which may miss the point or the analysis we may extract from that. > That is a very nice way of expressing it, except I would still say that it is not the visual system themselves that have the natural abstraction capabilities, it is a specialized part of our brain that extracts that automatically/unconsciously for us (what I called pattern matching (since it can only identify/notice things that it can match somehow)). But you expressed much better than I did why this is/would be so valuable. And I will check out the reference, thank you - the title sounds promising :). > For example, a very high level view of a profile or a trace, as a tree with just a one pixel wide line per item (with > identation according to depth + length related to some other execution property) may convey a lot about an execution. > > Another path that Alexandre Bergel makes wonder with is to use interaction to add and remove additional contextual > data; you can't do comparative analysis visually with that, but, given a fast system, you may scan for a large amount > of additional data without overloading the base display. I have used it to couple a code visualisation with a large C > source file, with hovering over nodes jumping instantaneously to the right place in the source, and this is really > effective for fast understanding of code structures (and loop / field of view focus effects). > >> Coming back to the WhyLine example, they already had something to >> (visually) look at: objects colliding. Other times, the visual >> representation is obvious/implied (say an algorithm for driving a car >> on a given course - even if all you are given are coordinates, it is >> common sense that you would draw the course on the screen and watch >> the car as it makes progress when the algorithm ticks). In many >> algorithms you don't have that. How do you find, in such cases, what >> pictures/graphs/animations to look at? For an algorithm one obvious >> candidate would be to the dynamic behavior of the main data >> structures used (although, say you do this for the car example and >> compare and contrast visualizing the data structures used by the >> algorithm vs visualizing the car moving, or the objects colliding). >> And you still have to find the right scale and level of abstraction. > > I guess here you have ideas: heat maps on data accesses, evolving over time; a representation of all objects in > memory, with their color which evolves according to freshness (animated). Could be very interesting to compare that > way two versions of the same algorithm, to see how they differ in time? Trace may be very valuable there, because it > may be tuned to record the type of events you are interested in, and then be exploited to build a visualisation on top. > > With experience, what I value now a lot is code interaction: anything that very easily couple the visualisation with > the relevant code (and not only the method, but the point in the code). I'm also dealing with safety properties of the > code: safe, correct multithreaded code, either through run time analysis (see VectorFabrics tools :)) or through > static analysis (Frama-C). > > Interesting subject and I am totally out of available work hours to implement stuff on that :) > > Thierry > Well, same here, and right now I am busy with another spare time project anyway (but I couldn't resist asking about your tools :) ), but if I ever manage to get back to polish that algorithm which has been in the back of my mind during this discussion (for the longest common subsequence), and which I worked on just for fun anyway, but which left me, as I said, with the nagging feeling that I could do more (and I don't mean some peephole optimization), I will try out some of these visualization techniques to see if anything comes out of it. Florin

Oct. 8, 2014

Re: [Pharo-dev] extract data from .mcz

by Alexandre Bergel

Thanks! It helps! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Oct 6, 2014, at 1:47 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Alexandre, > > On Mon, Oct 6, 2014 at 9:34 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Thanks Eliot. I know this. I meant code snippet to programmatically, within Pharo, do some queries. > > Such as? > > Some times ago I worked on a MCZ importer in Moose. I will have a look at it. > > The key is to ask a repository for the versions it has, get one or more versions, and create snapshots from these versions: > > > e.g. SpurBootstrapMonticelloPackagePatcher in VMMaker.oscog creates patched versions of packages. To create a repository, e.g. > > MCRepositoryGroup default repositories > detect: [:r| r description = url] > ifNone: [MCHttpRepository > location: url > user: 'squeak' > password: 'squeak'] > > but there's also the package cache: > > MCCacheRepository default > > You can ask them what versions they have: > > repository versionNamesForPackageNamed: package name > > You can create these versions, and store them: > > (trunk possiblyNewerVersionsOfAnyOf: latestUnbranched) do: > [:unpatched| > dest storeVersion: (trunk versionNamed: unpatched)] > > And you can create "snapshots" of these versions which contain all the definitions: > > version: version withPatches: patches for: package > | snapshot ancestry | > snapshot := MCPatcher > apply: (self patchForPackage: package withPatches: patches snapshot: version snapshot) > to: version snapshot. > ancestry := MCWorkingAncestry new addAncestor: version info. > ^MCVersion > package: version package > info: (ancestry > infoWithName: (self spurBranchNameForInfo: version info package: package) > message: version info name, > ' patched for Spur by ', > (CCodeGenerator shortMonticelloDescriptionForClass: self class), > '\\' withCRs, > version info message) > snapshot: snapshot > dependencies: {} "punt on computing dependencies; there are't any so far" > > > HTH > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Oct 6, 2014, at 1:25 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> Hi Alexandre, >> >> .mcz's are just zip files. The attached extracts the .st file as the package name with a .st extension instead of a .mcz extension. >> >> HTH >> >> On Mon, Oct 6, 2014 at 6:49 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi! >> >> Anyone has some code snippet to extract data from .mcz file ? >> Getting all the classes, doing some queries... >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> -- >> best, >> Eliot >> <mzex> > -- > best, > Eliot

Oct. 7, 2014

Re: [Pharo-dev] ShoreLine Reporter - A tool to collect stack traces

by Alexandre Bergel

Shouldnât the install script be: =-=-=-==-=-=-==-=-=-==-=-=-= StartupLoader default executeAtomicItems: { StartupAction name: 'ShoreLine-Reporter Installer' code: [ [ Gofer it smalltalkhubUser: 'dalsat' project: 'ShoreLine-Reporter'; configuration; load. (Smalltalk at: #ConfigurationOfShoreLineReporter) load. "Setting Reporter configuration" (Smalltalk at: #SlReporter) enabled: true. (Smalltalk at: #SlReporter) perform: #autoSubmit: with: true. (Smalltalk at: #SlReporter) perform: #showSummary: with: false. (Smalltalk at: #SlReporter) perform: #showNotification: with: true. ] asJob run ] runOnce: true. }. =-=-=-==-=-=-==-=-=-==-=-=-= Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Oct 7, 2014, at 1:23 PM, Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com> wrote: > Hello everybody, > > for those of you who were not at ESUG, I present ShoreLine Reporter. > > ShoreLine Reporter is a Pharo plugin to collect stack traces from exceptions and send them to a central repository. > You can give feedback to the community by breaking things: how cool is that? > > > * Why? > > We are collecting stack traces for research purposes and to identify the Pharo components that can be improved or optimized. > We are also working on a web platform where users can access the submitted data and use them during the debugging process. More on that soon! > > > * How? > > You can install ShoreLine Reporter by visiting the project page on SmalltalkHub: > http://www.smalltalkhub.com/#!/~dalsat/ShoreLine-Reporter/ > > Installing ShoreLine Reporter requires only a couple of seconds, and you can configure it with the level of feedback that you prefer. On the SmalltalkHub page you can find a script to automatically install ShoreLine Reporter with every new Pharo image. Just drop it in your Pharo preferences directory and forget about it. > > Once ShoreLine Report is installed, you can decide to configure if you want to be prompted to submit a stack trace, or to automatically submit each exception without any bother. > > > * What? > > We try to collect as few data as possible: the execution stacktrace, the name of the author and the Pharo build. We do *not* any collect personal data, such as passwords or repositories. The data is currently stored on our server, at the University of Lugano. > > > * Compatibility > > ShoreLine Reporter is developed for the Pharo debugger. We are improving ShoreLine Reporter to work with GTInspector, we will push an update in the following days. > > > For any problem, contact me! > > Thanks, hope to see a lot of your exceptions ;-) > Tommaso Dal Sasso @ REVEAL >

Oct. 7, 2014

Re: [Pharo-dev] FOSDEM > Looks like there is a Smalltalk room :)

by Stephan Eggermont

Yes, I'll put the CFP out soon. Stephan

Oct. 7, 2014

Re: [Pharo-dev] Assigning to Block and Method arguments

by Esteban A. Maringolo

If I evaluate: (CodeImporter evaluateFileNamed: 'foo.st') In a headless pharo image, does it count as interactive? Regards! Esteban A. Maringolo 2014-10-07 16:31 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Indeed, I like this approach. Nicely done. > > Doru > > On Tue, Oct 7, 2014 at 9:11 PM, stepharo <stepharo(a)free.fr> wrote: >> >> This sounds like a good strategy this difference between interactive and >> loading time. >> >> >> On 7/10/14 18:25, Marcus Denker wrote: >>> >>> Hi, >>> >>> In Pharo3 we had the bug that assigning to method arguments was allowed. >>> >>> *Block* arguments are traditionally assignable, but this is equally a bad >>> idea (there was already a setting >>> to forbid it, but no idea how to make it a default without making a lot >>> of code unlovable). >>> >>> First we made method arg assignment in Pharo4 an error, like it was in >>> Pharo2, but >>> the problem with that is that there is code out there alreadyâ¦ so (thanks >>> to Nicolai Hess), >>> now assignments to method arguments raise an error in interactive mode >>> (when coding), but >>> load fine e.g. with Monticello. >>> >>> Yesterday I extended that scheme to block arguments: Now block argument >>> assignments >>> are forbidden in interactive mode, while legacy code loads fine. >>> >>> (I removed the #allowBlockArgumentAssignment setting, too). >>> >>> This way we have a good transition and in some versions can make raising >>> errors on assignments >>> to arguments the default even in non-interactive mode. >>> >>> Marcus >>> >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 7, 2014

Re: [Pharo-dev] Assigning to Block and Method arguments

by Tudor Girba

Indeed, I like this approach. Nicely done. Doru On Tue, Oct 7, 2014 at 9:11 PM, stepharo <stepharo(a)free.fr> wrote: > This sounds like a good strategy this difference between interactive and > loading time. > > > On 7/10/14 18:25, Marcus Denker wrote: > >> Hi, >> >> In Pharo3 we had the bug that assigning to method arguments was allowed. >> >> *Block* arguments are traditionally assignable, but this is equally a bad >> idea (there was already a setting >> to forbid it, but no idea how to make it a default without making a lot >> of code unlovable). >> >> First we made method arg assignment in Pharo4 an error, like it was in >> Pharo2, but >> the problem with that is that there is code out there alreadyâ¦ so (thanks >> to Nicolai Hess), >> now assignments to method arguments raise an error in interactive mode >> (when coding), but >> load fine e.g. with Monticello. >> >> Yesterday I extended that scheme to block arguments: Now block argument >> assignments >> are forbidden in interactive mode, while legacy code loads fine. >> >> (I removed the #allowBlockArgumentAssignment setting, too). >> >> This way we have a good transition and in some versions can make raising >> errors on assignments >> to arguments the default even in non-interactive mode. >> >> Marcus >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 7, 2014