December 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo Trick: #0009] 'Enable halt/inspect once' button

by Max Leske

#setHaltOnce is implemented on Object. Evaluate this in a workspace: self setHaltOnce. -> same effect Cheers, Max On 12.12.2013, at 13:06, btc(a)openInWorld.com wrote: > When I have a 'self haltOnce' breakpoint that I am activating often, going "World > System > Enable halt/inspect once" each time is annoying. So using the Duplicate Halo on the menu item, I drag it onto the background so that it acts like a button. > > cheers -ben >

Dec. 12, 2013

Re: [Pharo-dev] [Pharo Trick: #0001] - Simple TODO list

by Esteban Lorenzano

I use it too, and I think they are a nice add that the tools should be more aware (not just showing the flag icon in browser) On Thu, Dec 12, 2013 at 1:05 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 12 Dec 2013, at 12:58, Torsten Bergmann <astares(a)gmx.de> wrote: > > > Did you check the number of senders of #flag: in a recent Pharo image? > You > > will be surprised that not all come from Squeak ;) > > > I use it, yes. > > Marcus > >

Dec. 12, 2013

[Pharo Trick: #0009] 'Enable halt/inspect once' button

by btc＠openinworld.com

When I have a 'self haltOnce' breakpoint that I am activating often, going "World > System > Enable halt/inspect once" each time is annoying. So using the Duplicate Halo on the menu item, I drag it onto the background so that it acts like a button. cheers -ben

Dec. 12, 2013

Re: [Pharo-dev] [Pharo Trick: #0001] - Simple TODO list

by Marcus Denker

On 12 Dec 2013, at 12:58, Torsten Bergmann <astares(a)gmx.de> wrote: > Did you check the number of senders of #flag: in a recent Pharo image? You > will be surprised that not all come from Squeak ;) > I use it, yes. Marcus

Dec. 12, 2013

Re: [Pharo-dev] [Pharo Trick: #0008] - If appropriate use the memory file system

by Torsten Bergmann

Hi Marcus, regarding 2) In Pharo 3.0 one can already open a file browser on the memory file system: |fs| fs := FileSystem memory. (fs / 'hello.txt') writeStreamDo: [:s| s nextPutAll: 'Exported data' ]. FileList openOn: fs root but it looks like it needs some love. One can create new files but most functionality will not work. Should we create an issue? Thx T. > Gesendet: Donnerstag, 12. Dezember 2013 um 12:44 Uhr > Von: "Marcus Denker" <marcus.denker(a)inria.fr> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] [Pharo Trick: #0008] - If appropriate use the memory file system > > Related to that: > > For Pharo4 I want to experiment to have the following: > > 1) one Memory FileSystem per RPackage (just an ivar there). > 2) File Browser support to show all these so one can put files in the package filesystem > 3) in Monticello, save all the files as part of the .zip (directory âresourcesâ) > 4) When loading with MC, load all files from the resources dir into the package filesystem > > (at first the file support will be very simple, e.g. no support for diffs). > > ==> then store e.g. all the icons there instead of a MIME-Encode string. > > Marcus > > On 12 Dec 2013, at 12:39, Torsten Bergmann <astares(a)gmx.de> wrote: > > > ----------------------------------------------------------------------------------- > > [Pharo Trick: #0008] - If appropriate use the memory file system > > ----------------------------------------------------------------------------------- > > Works in: Pharo 2.0, 3.0, ... > > ----------------------------------------------------------------------------------- > > > > It may be possible that your application has to export some > > data into an external file in a specific format. Pharo allows writing into > > a file using Streams as any other Smalltalk. > > > > But sometimes you want to check the result right from the Pharo image > > without having to look into the external file using external tools. > > > > So the trick here is to use the memory file system instead > > of the real disk file system during development since also no > > cleanup on the hard disk is required afterwards: > > > > |fs| > > fs := FileSystem memory. > > (fs / 'hello.txt') writeStreamDo: [:s| s nextPutAll: 'Exported data' ]. > > (fs / 'hello.txt') readStream contents. > > > > The memory filesystem is also nice if you need to work with files > > within a unit test. So when the test runs nothing remains left on the > > hard disk. > > > > If you need a real copy of the file on the hard disk you can also copy > > from the memory file system to the disk file system using #copyTo: > > > > |fs| > > fs := FileSystem memory. > > (fs / 'hello.txt') writeStreamDo: [:s| s nextPutAll: 'Memory first and then disk' ]. > > (fs / 'hello.txt') copyTo: (FileSystem disk / 'exactCopy.txt') > > > > > > >

Dec. 12, 2013

Re: [Pharo-dev] [Pharo Trick: #0001] - Simple TODO list

by Torsten Bergmann

Did you check the number of senders of #flag: in a recent Pharo image? You will be surprised that not all come from Squeak ;) By sharing I want to just show what is possible and others may find it valuable for their own work in the given or in a customized form. It is not a "best practice", more a "these things helped me" and as a source of inspiration. Bye T. Gesendet:Â Donnerstag, 12. Dezember 2013 um 11:20 Uhr Von:Â "Nicolas Cellier" <nicolas.cellier.aka.nice(a)gmail.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] [Pharo Trick: #0001] - Simple TODO list I don't much like this nice idea.Why? see all the (self flags: #toRemove) and such kind of annotations in Squeak.Then tend to last much longer than due.A todo list should have a (short) expiration date.Maybe a method with expired todo should be purely and simply erased ;) Â 2013/12/12 Serge Stinckwich <serge.stinckwich(a)gmail.com>Nice idea Torsten, this kind of tricks ;-) Maybe we can save them online somewhere ? gists.github.com[http://gists.github.com] ? On Wed, Dec 11, 2013 at 12:16 PM, Torsten Bergmann <astares@gmx.de[astares@gmx.de]> wrote: > Hi, > > the mailinglist, stackoverflow and other Pharo related medias are typically used > in the "here is a question to problem" followed by an "answer from community" style. > > But lets also think the other way around: if we already have a solution for a > problem that others may have too or may have in the future we should share the > answer/solution as well. > > I'm sure many of you have some tricks that make developing with Pharo much easier > and others can profit from these tricks if we share them here on the list. > > Be it > Â - a simple and useful script > Â - a simple key combination other may not yet know of > Â - a package one can use or how you use it > Â - a link to a nice description on the web related on how to use Pharo > Â - a custom tool that makes development easier > Â - an algorithm or something that you think was solved very elegant > Â - a way you solved a common problem easily in your app > Â - ... > > Then just describe it in a few lines and post it. Also write in which Pharo > version you tried it - this makes it easier for others to see in which > version the trick/solution is known to work. > > The idea goes like this: if you have a trick to share then send a mail with > subject "Pharo Trick: #xxxx] - Short Description" to the Pharo dev AND Pharo user > list (see http://lists.pharo.org[http://lists.pharo.org]) Make sure to increase the trick counter xxxx. > > Using this special subject one can later easily get the tricks from the > mailinglist archive. Also others can refer to the trick if it solves a common > problem other may ask for on the list. > > Lets see if we are able to reach the goals of 100, 1000 or more Pharo tricks ;) > > Bye > T. > > > I will start with something easy but useful: > > ----------------------------------------------------------------------------------- > [Pharo Trick: #0001] - Simple TODO > ----------------------------------------------------------------------------------- > Works in: Pharo3.0 Latest update: #30635 but should work in other versions too > ----------------------------------------------------------------------------------- > > If you develop an app with Pharo you may not yet fully implement all features. > Some kind of marker for future "ToDo's" is often needed. Using a pragma on a method is > the easiest solution here: > > Â Â foo > Â Â Â <todo: 'Add world later'> > Â Â Â "That method is not yet fully implemented" > > Â Â Â Transcript show: 'Hello' > > > Using a simple expression in the workspace you can browse all the TODOs for your > project afterwards in a window: > > Â Â SystemNavigation default browseAllSendersOf: #todo: > > You can even query the system for the todo descriptions if you need the full > list of things to work on: > > Â (PragmaCollector filter: [:prg | prg keyword = 'todo:']) > Â Â Â Â reset; > Â Â Â Â collect: [:each| each arguments first ] > > As the pragma keyword #todo: is very common and may be used by others too > it may be wise to use a custom one like "myappplicationTodo:" or similar. > ----------------------------------------------------------------------------------- > Â -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/[http://www.doesnotunderstand.org/] Â

Dec. 12, 2013

Re: [Pharo-dev] could we stop to create spaghetti code?

by Esteban Lorenzano

so far icons are all packed together into an icon pack. for example, Pharo3Icons and FamFamIcons. all tools should register their icons there, as extensions of a theme. then, a method: MyClass clas>>#icon ^ Smalltalk ui icons iconNamed: #myIcon can provide enough decoupling. then... is in tool developers the responsibility of follow the pattern (a pattern that is already there, no need of new stuff). Esteban On Thu, Dec 12, 2013 at 12:25 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > >> > > > > I think the idea here is that maybe a class should have an icon. > Independend of Nautilus.\ > > (either just icon or toolIcon). > > > > Marcus > > > > > > In a great environment you have icons and icon-sets defined by UX/UI > designers. > > If we couple too much to code we'll create a barrier for that. > > If Nautilus (or whatever other browser) wants to display icons in classes > and packages (which I found great) it should itself provide the code for > that without system intrusion/pollution for the sake of being lazy > > Idea: > > Classes: > > NautilusIconSet > HottishIcons > CoolishIcons > > > WhoeverDisplaysTheClassListItems>>iconFor: aClass > "Returns the icon for aClass or a default icon" > > ^ aNautilusIconSet > at: Integer > ifAbsent:[self defaultIcon] > >

Dec. 12, 2013

Re: [Pharo-dev] [Pharo Trick: #0008] - If appropriate use the memory file system

by Marcus Denker

Related to that: For Pharo4 I want to experiment to have the following: 1) one Memory FileSystem per RPackage (just an ivar there). 2) File Browser support to show all these so one can put files in the package filesystem 3) in Monticello, save all the files as part of the .zip (directory âresourcesâ) 4) When loading with MC, load all files from the resources dir into the package filesystem (at first the file support will be very simple, e.g. no support for diffs). ==> then store e.g. all the icons there instead of a MIME-Encode string. Marcus On 12 Dec 2013, at 12:39, Torsten Bergmann <astares(a)gmx.de> wrote: > ----------------------------------------------------------------------------------- > [Pharo Trick: #0008] - If appropriate use the memory file system > ----------------------------------------------------------------------------------- > Works in: Pharo 2.0, 3.0, ... > ----------------------------------------------------------------------------------- > > It may be possible that your application has to export some > data into an external file in a specific format. Pharo allows writing into > a file using Streams as any other Smalltalk. > > But sometimes you want to check the result right from the Pharo image > without having to look into the external file using external tools. > > So the trick here is to use the memory file system instead > of the real disk file system during development since also no > cleanup on the hard disk is required afterwards: > > |fs| > fs := FileSystem memory. > (fs / 'hello.txt') writeStreamDo: [:s| s nextPutAll: 'Exported data' ]. > (fs / 'hello.txt') readStream contents. > > The memory filesystem is also nice if you need to work with files > within a unit test. So when the test runs nothing remains left on the > hard disk. > > If you need a real copy of the file on the hard disk you can also copy > from the memory file system to the disk file system using #copyTo: > > |fs| > fs := FileSystem memory. > (fs / 'hello.txt') writeStreamDo: [:s| s nextPutAll: 'Memory first and then disk' ]. > (fs / 'hello.txt') copyTo: (FileSystem disk / 'exactCopy.txt') > >

Dec. 12, 2013

[Pharo Trick: #0008] - If appropriate use the memory file system

by Torsten Bergmann

----------------------------------------------------------------------------------- [Pharo Trick: #0008] - If appropriate use the memory file system ----------------------------------------------------------------------------------- Works in: Pharo 2.0, 3.0, ... ----------------------------------------------------------------------------------- It may be possible that your application has to export some data into an external file in a specific format. Pharo allows writing into a file using Streams as any other Smalltalk. But sometimes you want to check the result right from the Pharo image without having to look into the external file using external tools. So the trick here is to use the memory file system instead of the real disk file system during development since also no cleanup on the hard disk is required afterwards: |fs| fs := FileSystem memory. (fs / 'hello.txt') writeStreamDo: [:s| s nextPutAll: 'Exported data' ]. (fs / 'hello.txt') readStream contents. The memory filesystem is also nice if you need to work with files within a unit test. So when the test runs nothing remains left on the hard disk. If you need a real copy of the file on the hard disk you can also copy from the memory file system to the disk file system using #copyTo: |fs| fs := FileSystem memory. (fs / 'hello.txt') writeStreamDo: [:s| s nextPutAll: 'Memory first and then disk' ]. (fs / 'hello.txt') copyTo: (FileSystem disk / 'exactCopy.txt')

Dec. 12, 2013

Re: [Pharo-dev] could we stop to create spaghetti code?

by Sebastian Sastre

>> > > I think the idea here is that maybe a class should have an icon. Independend of Nautilus.\ > (either just icon or toolIcon). > > Marcus > > In a great environment you have icons and icon-sets defined by UX/UI designers. If we couple too much to code we'll create a barrier for that. If Nautilus (or whatever other browser) wants to display icons in classes and packages (which I found great) it should itself provide the code for that without system intrusion/pollution for the sake of being lazy Idea: Classes: NautilusIconSet HottishIcons CoolishIcons WhoeverDisplaysTheClassListItems>>iconFor: aClass "Returns the icon for aClass or a default icon" ^ aNautilusIconSet at: Integer ifAbsent:[self defaultIcon]

Dec. 12, 2013