February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Clickable Source Code

by Tudor Girba

Hi, Sounds cool. This is since a long time on the wish-list of Glamour :): http://www.moosetechnology.org/tools/glamour/Ideas Just a question. Does the implementation hardcode opening the browser? It would be cool to have it customizable such that it can be used in other contexts as well. Also, I would be interested in getting specific behavior on cmd+click, too. Cheers, Doru On 1 Feb 2012, at 20:54, Camillo Bruni wrote: > hi everyone, > > Today I hacked the ST80 Styler to support clickable source code links: > > - clicking on a Class name opens a Browser > - clicking on a instVar shows al users of it > ... > > The current limitation is the mouse-handling. Right now I run the actions on normal > clicks, not really nice. I wish to only run an action on cmd-click (like in eclipse). > > However left / middle / right clicks are already handled high up in the morphic tree > to generate these mostly useless menues... > > So I wonder is there a way to only get register for ctrl-click / alt-click / cmd-click? > > best > cami -- www.tudorgirba.com "What we can governs what we wish."

Feb. 1, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Dale Henrichs

Getting deeper in FSGit and it looks like it has a Monticello mapping ... now to work:) Dale ----- Original Message ----- | From: "Stefan Marr" <smalltalk(a)stefan-marr.de> | To: Pharo-project(a)lists.gforge.inria.fr | Cc: metacello(a)googlegroups.com, "Bruni camillo" <camillobruni(a)gmail.com> | Sent: Wednesday, February 1, 2012 11:02:16 AM | Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only? | | | On 01 Feb 2012, at 19:45, Dale Henrichs wrote: | | > I haven't completely grokked the entire FSGit experience, however | > the piece that has intrigued me with the filetree repository that | > Otto has done is the fusion between monticello and "git" | > (technically filetree doesn't depend upon git, it just stores | > monticello package information in a structured directory tree). So | > filetree can be used as the basis for integrating any file-based | > SCM into Smalltalk...personally I will focus on git... | > | > Basically, I have taken myself up on the challenge to provide a git | > workflow experience for Smalltalk:) and my approach is to create a | > fusion of Monticello, Metacello, and git... | | Cool! | | Camillo, did you plan be in Brussels on Saturday for the sprint? | Would that be something to pair on for a few hours? | | Best regards | Stefan | | | | -- | Stefan Marr | Software Languages Lab | Vrije Universiteit Brussel | Pleinlaan 2 / B-1050 Brussels / Belgium | http://soft.vub.ac.be/~smarr | Phone: +32 2 629 2974 | Fax: +32 2 629 3525 | | |

Feb. 1, 2012

[Pharo-project] Clickable Source Code

by Camillo Bruni

hi everyone, Today I hacked the ST80 Styler to support clickable source code links: - clicking on a Class name opens a Browser - clicking on a instVar shows al users of it ... The current limitation is the mouse-handling. Right now I run the actions on normal clicks, not really nice. I wish to only run an action on cmd-click (like in eclipse). However left / middle / right clicks are already handled high up in the morphic tree to generate these mostly useless menues... So I wonder is there a way to only get register for ctrl-click / alt-click / cmd-click? best cami

Feb. 1, 2012

[Pharo-project] keeping up with lively-kernel (morphic)

by Lawson English

It seems to me that the most active place where development of Morphic is taking place is in the context of Lively Kernel. Is anyone tracking what the LK people are doing and seeing how it can be backported, or used to create a new version, or integrated with the current version of Morphic or Cuis, etc? Lawson

Feb. 1, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Stefan Marr

On 01 Feb 2012, at 19:45, Dale Henrichs wrote: > I haven't completely grokked the entire FSGit experience, however the piece that has intrigued me with the filetree repository that Otto has done is the fusion between monticello and "git" (technically filetree doesn't depend upon git, it just stores monticello package information in a structured directory tree). So filetree can be used as the basis for integrating any file-based SCM into Smalltalk...personally I will focus on git... > > Basically, I have taken myself up on the challenge to provide a git workflow experience for Smalltalk:) and my approach is to create a fusion of Monticello, Metacello, and git... Cool! Camillo, did you plan be in Brussels on Saturday for the sprint? Would that be something to pair on for a few hours? Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Feb. 1, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Dale Henrichs

Igor, Otto's filetree stores monticello package meta data in the repository as well ... the basic model is to store the Monticello meta data ... having spent the last two days developing with filetree I have noticed an interesting side effect of storing meta data and source ... when you merge (using the git level merge) you end up having to resolve conflicts in the meta data and the source code ... I assume that this is a solvable problem (maybe even git has an answer?), but it is worth considering ... Another thing to consider with meta data is that with a file-based system folks will very likely do edits to the source files directly including potentially the meta data files .... like a said, maybe git has a way to hide meta data files from mere mortals, but if not one must be a bit careful... Dale ----- Original Message ----- | From: "Igor Stasenko" <siguctua(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, February 1, 2012 7:20:12 AM | Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only? | | On 1 February 2012 16:12, Frank Shearar <frank.shearar(a)gmail.com> | wrote: | > On 1 February 2012 14:44, Damien Pollet <damien.pollet(a)gmail.com> | > wrote: | >> On 31 January 2012 15:59, Otto Behrens <otto(a)finworks.biz> wrote: | >>> I was wondering more if it is possible to do without having a | >>> file | >>> system checkout of the class definition. In other words, if the | >>> class | >>> definition in the image could serve as the working copy of the | >>> object | >>> in the git repository. I must read more on what the other guys | >>> did | >>> with the git interfaces (such as gitfs and gitosis) to understand | >>> what | >>> it comes down to. | >>> | >>> If this is possible, it would make merging, loading and | >>> committing | >>> essentially one step. | >> | >> Have you seen what Camillo did? | >> http://www.squeaksource.com/FSGit | >> https://github.com/dh83/fs-git-test | >> | >> Note the layout with class comment in a README file, etc :) | > | > That is _exactly_ the right thing to do! Bravo, Camillo! Also note | > how | > Nested-Package-Names end up looking like you might expect. | > | > Is there any necessity for storing a chunk? For instance in | > https://github.com/dh83/fs-git-test/blob/master/AAA/AAA.class/instance-side… | > we have | > | > !AAA methodsFor: 'as yet unclassified' stamp: 'CamilloBruni | > 1/23/2012 19:15'! | > a | > Â Â Â Â | a | | > Â Â Â Â ^ a! ! | > | > with the ugly chunk !s. The only thing we can't directly regenerate | > is | > the timestamp: modulo that, we know the class name, the category | > (the | > name of the directory you're in), the author (from the author of | > the | > git commit). You'd have a disconnect between the git commit time | > and | > the time in the chunk which would, IIRC, be the time you hit Alt-S | > in | > your browser? Or would that be file-out time, which would likely | > then | > be the timestamp in the git commit? | > | | Good question, Frank. | But i want to go even further by saying: | why we cannot associate an arbitrary meta-information per method and | store it along with method? | | Today we storing the category, author and stamp. | Tomorrow we may want to add something more (link to documentation, | link to previous version etc etc) | And i think , at least in GitFS Camillo can do it pretty easy. | If you have 1 file per method, make 2 files per method, i.e.: | | methodname.st | methodname.meta | | and in meta, we can store everything we want in a form we want. while | .st is for storing purely smalltalk source code, and nothing else. | | -- | Best regards, | Igor Stasenko. | |

Feb. 1, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Dale Henrichs

I haven't completely grokked the entire FSGit experience, however the piece that has intrigued me with the filetree repository that Otto has done is the fusion between monticello and "git" (technically filetree doesn't depend upon git, it just stores monticello package information in a structured directory tree). So filetree can be used as the basis for integrating any file-based SCM into Smalltalk...personally I will focus on git... Basically, I have taken myself up on the challenge to provide a git workflow experience for Smalltalk:) and my approach is to create a fusion of Monticello, Metacello, and git... For an alternate SCM to get traction within the community, I think that there needs to be easy migration between this alternate approach and Monticello and for me filetree was the missing piece ... If you want to see what I am currently up to, take a look at the metacello project on github[1]. Take a look at the network view[2] of the project. I've pushed the Metacello code for 1.0-beta.31[6] (the latest release) into the repository using filetree[3], essentially a fork of Otto's smallsource project[4]. I've also pushed the code for my current work-in-progress for 1.0-beta.32[5]. Finally I created the MetacelloGitProject[7] branch for the project, where I have started doing development (one must eat their own dog food!) using github as the sole repository for my code (other than local clones on my work desktop machine and my home laptop). You can look at one of my commits[8] from last night where you can see a nice difference view that actually involves changes to 4 monticello packages ... I do a fair amount of the actual loading manually as I'm still trying to get a feel for using git in development...FSGit looks very interesting as well, if we are going to use git, then having a Smalltalk interface to git is a requirement ... filetree is SCM neutral, but I am building an extension of filetree that is aimed at git (in git, the repository is versioned not the individual files, so it is an interesting challenge to integrate into Monticello). I am very encouraged that the fusion of Monticello, Metacello and git is coming together pretty nicely (i.e., without tons of work)...this is very early work, so I don't recommend anyone actually try to use the project (it is only 2 days old:) as there is a fair amount of hand holding that I have to do right now ... However, if you are interested in contributing then I encourage you to fork the metacello project on github[1] and get busy. I will report progress and solicit feedback in general on the metacello mailing list[9], but if there is interest in collaborating we'll just use github for the nitty gritty communication. Dale [1] https://github.com/dalehenrich/metacello [2] https://github.com/dalehenrich/metacello/network [3] https://github.com/dalehenrich/filetree [4] https://github.com/finworks/smallsource [5] https://github.com/dalehenrich/metacello/tree/1.0-beta.32 [6] https://github.com/dalehenrich/metacello/tree/1.0-beta.31 [7] https://github.com/dalehenrich/metacello/tree/MetacelloGitProject [8] https://github.com/dalehenrich/metacello/commit/b79df4a2cd63200a8a1712fe629… [9] http://groups.google.com/group/metacello ----- Original Message ----- | From: "Damien Pollet" <damien.pollet(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr, "Bruni camillo" <camillobruni(a)gmail.com> | Sent: Wednesday, February 1, 2012 6:44:37 AM | Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only? | | On 31 January 2012 15:59, Otto Behrens <otto(a)finworks.biz> wrote: | > I was wondering more if it is possible to do without having a file | > system checkout of the class definition. In other words, if the | > class | > definition in the image could serve as the working copy of the | > object | > in the git repository. I must read more on what the other guys did | > with the git interfaces (such as gitfs and gitosis) to understand | > what | > it comes down to. | > | > If this is possible, it would make merging, loading and committing | > essentially one step. | | Have you seen what Camillo did? | http://www.squeaksource.com/FSGit | https://github.com/dh83/fs-git-test | | Note the layout with class comment in a README file, etc :) | | There is a also nearly working implementation of the git network | protocol (stubbed using the git binaries ATM). | | | > The disadvantage could be a tight coupling with git. | | is that really a disadvantage, compared to a tight coupling with | monticello? | | | -- | Damien Pollet | type less, do more [ | ] http://people.untyped.org/damien.pollet | |

Feb. 1, 2012

Re: [Pharo-project] Issue 5229: Removing the global use of UserInterruptHandler in favor of an inst var in the current Sensor

by Fernando Olivero

Nothing prevents from registering an instance of UserInterruptHandler , outside the Sensor code. But i've noticed that this registering was done in #installEventSensorFramework:, and no reference to the interrupt handler was kept by the Sensor. So made me think that Sensor should keep a reference to it. The question is wether we need a special case for the UserInterruptHandler, i think we should not. By special case i mean, an extra single purpose "Sensor". It could be done more transparently by relying on a single Sensor. Evidence of it is that UserInterruptHandler can be customized for any keystroke, yet the settings are called CmdDotEnabled. Using the new Event-Model, user interrupts can be customized by the client processing the system events, no need to have a special user interrupt handler class. The client would process a normal SystemKeyboardInputEvent, and do whatever it wants in case the keystroke was the current user-interrupt keystroke. For example, in Gaucho : GKeyboard>>keystroke: aGKeystroke â¦. aGKeystroke isUserInterrupt ifTrue:[ userInterface processUserInterrupt ]. ... In Morphic, the HandMorph would have this responsibility. Or we can push this bypassing of the keystroke handling to the SystemEventsAnnouncer. Does it make sense? Fernando On Wed, Feb 1, 2012 at 4:13 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > err... you seems like crossing multiple layers by doing that. > > Because before you were able to have interrupt handler without having a sensor. > Now you cannot have interrupt handler without having sensor installed. > > On 1 February 2012 14:14, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> Please integrate/review this one. >> >> >> In the context of replacing the current event handling mechanism, for >> the new Event-Model using announcements, i found out that the >> UserInterruptHandler is somehow treated as a global. >> >> See >> >> Â InputEventSensor>>installEventSensorFramework: fetcherClass. >> Â Â â¦. >> Â Â "Register the interrupt handler" >> Â Â UserInterruptHandler new registerIn: InputEventFetcher default. >> Â Â â¦â¦. >> >> What if you want to replace the user interrupt handler for another? It >> cant be done transparently. >> >> I've added the userInterruptHandler as an ivar of the current Sensor, >> so when it registers and unregisters, it takes care of registering and >> unregistering its user interrupt handler. >> >> So you can plug different user interrupt handlers to the current sensor. >> >> >> >> >> Fernando >> > > > > -- > Best regards, > Igor Stasenko.

Feb. 1, 2012

Re: [Pharo-project] pdf4smalltalk Re: pharo vision

by Esteban Lorenzano

Hi, I'm using libharu with HPDF and is going well... maybe we can build a better smalltalk-side package (HPDF is good, but basic) and rely on an existing library, instead reinvent the wheel this time :) best, Esteban El 01/02/2012, a las 1:22p.m., S Krish escribiÃ³: > Additionally why not look at using XMLRPC bridge to do Jasper > Reports.. or even CrystalReports.. > > Of course this will require little bit of backend work on a Groovy / > Ruby/ Python > > or Webservice link to JasperServer.. if its commercial.. > > or Ruby for its fairly workable pdf writer.. > > Great though to have a fully functional pdf writer in Smalltalk/ Pharo. > > On 2/1/12, Ben Coman <btc(a)openinworld.com> wrote: >> It took some hunting but I finally found the source located here... >> http://pdf4smalltalk.origo.ethz.ch/wiki/store_access >> >> with MIT License specified here... >> http://pdf4smalltalk.origo.ethz.ch/ >> >> That looks quite promising. >> >> cheers, Ben >> >> >> StÃ©phane Ducasse wrote: >>> On Jan 31, 2012, at 5:13 PM, Ben Coman wrote: >>> >>> >>>> Stef, >>>> >>>> I've sent some markup directly, some additional ideas - perhaps only for >>>> later and/or more of a library than core functionality. >>>> >>>> Improved printing subsystem - by which I mean PDF output. >>>> Business proposition: Without good PDFs many contemporary business >>>> practices are curtailed. For example, multi-page reporting charts being >>>> emailed to external clients. >>>> >>> >>> Are you aware of the open-source library of Christian Haider? >>> >>> >>>> Running multiple images on one VM with copy-on-write shared memory. >>>> Business proposition: To allow more images (owned by different clients) >>>> to be run (presumably) with less resources on resource limited web server >>>> platforms. >>>> >> >> >> >

Feb. 1, 2012

Re: [Pharo-project] Collection new

by S Krish

Does not work all the time in busy loops.. it continues with other debugger windows. Would love it if Alt . completely stops all other processing.. some kind of master interrupt... On 2/1/12, Milan Mimica <milan.mimica(a)gmail.com> wrote: > On 31 January 2012 06:18, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > >> In general why is there not a catch all for Stack Overflow and infinite >> loops. > > > In general, you just press Alt+., several times. > > > > -- > Milan Mimica > http://sparklet.sf.net >

Feb. 1, 2012