May 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] mentor question 4

by Richard O'Keefe

Why does it make no sense? To a first approximation, aCollection asWHATEVER = WHATEVER withAll: aCollection Consider 'CAB' asSet 'CAB' asArray 'CAB' asSortedCollection 'CAB' asBag and so on. They all mean "an instance of the class named in the selector with the elements of the receiver." Why should #asString be any different? Why on earth does #($a $b $c) asString make no sense when #($a $b $c) as: String -- which we expect to do the same thing -- DOES apparently make sense? Note that when I'm talking about #asString, I haven't the slightest thought in my mind about user interfaces. I am talking about a selector in the 'converting' category which I expect to act just like other methods in the same category. I am talking about expecting _ as: String and _ asString to be consistent the way that _ as: Array and _ asArray are. I am talking about "if it is OK to convert a String to an Array, why can't I convert that Array back to a String using the same pattern of code"? #printString exists. #storeString exists. #displayString exists -- although I have never seen a clear description of exactly what it is supposed to do and how it is supposed to differ from #printString, and it is certainly not portable. If I want the effect of any one of these, I am going to use it and NOT #asString. If I want to convert an Array or a Set to a String with the same elements, I am going to expect #asString to do it. When #asString is inconsistent with all the other #asWHATEVER methods, I am going to regard it as a bug. How about a compromise? Collection>>asString ^(self allSatisfy: [:each | each isCharacter]) ifTrue: [String withAll: self] ifFalse: [super asString] On Fri, 15 May 2020 at 02:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > On 11 May 2020, at 23:19, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > I was saying that I expected #($a $b $c) asString ==> 'abcâ. > > > To me it makes no sense. > I do not understand what is asString in fact. > > > If you want something that can be read back, that's what #storeString is > for, > > On Tue, 12 May 2020 at 01:28, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > > > > On 5 May 2020, at 16:16, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > By the way, while playing with this problem, I ran into a moderately > painful issue. > > There is a reason that Smalltalk has both #printString (to get a > printable representation of an object) and #asString (to convert a > sequence to another kind of sequence with the same elements.) If I > *want* #printString, I know where to find it. The definition in my > Smalltalk no reads > > asString > "What should #($a $b $c) do? > - Blue Book, Inside Smalltalk, Apple Smalltalk-80: > there is no #asString. > - ANSI, VW, Dolphin, CSOM: > #asString is defined on characters and strings > (and things like file names and URIs that are sort of strings), > so expect an error report. > - VisualAge Smalltalk: > '($a $b $c)' > - Squeak and Pharo: > '#($a $b $c)' > - GNU Smalltalk, Smalltalk/X, and astc: > 'abc' > I don't intend any gratuitous incompatibility, but when there > is no consensus to be compatible with, one must pick something, > and this seems most useful. > " > ^String withAll: self > > Does anyone here know WHY Squeak and Pharo do what they do here? > > > Oops I did not see the quotes on my screen.. > > #( a b c) asString > > '#(#a #b #c)â > > > this is unclear to me why this is not good but I have no strong opinion > that this is good. > > I worked on printString for literals because I wanted to have > self evaluating properties for basic literal like in Scheme and others. > where > #t > > > #t > > And I payed attention that we get the same for literal arrays. > Now the conversion is open to me. > > #($a $b $c) asString > > > '#($a $b $c)â > > In fact I do not really understand why a string > > #($a $b $c) asString would be '(a b c)â > and its use > if this is to nicely display in the ui I would have > displayString doing it. > > S. > > > > On Wed, 6 May 2020 at 01:20, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > The irony is that the code I was responding to ISN'T obviously correct. > Indeed, I found it rather puzzling. > The problem specification says that the input string may contain digits > AND SPACES. The original message includes this: > > Strings of length 1 or less are not valid. Spaces are allowed in the > input, but they should be stripped before checking. All other > non-digit characters are disallowed. > > Now it isn't clear what "disallowed" means. I took it to mean "may occur > and > should simply mean the input is rejected as invalid." Perhaps "may not > occur" > was the intention. So we shall not quibble about such characters. > > But I can't for the life of me figure out how Trygve's code checks for > spaces. > One reason this is an issue is that the behaviour of #digitValue is not > consistent between systems. > Character space digitValue > does not exist in the ANSI standard > answers -1 in many Smalltalks (which is a pain) > answers a positive integer that can't be mistake for a digit in my > Smalltalk > raises an exception in some Smalltalks. > > This is a comment I now have in my Smalltalk library for #digitValue > "This is in the Blue Book, but unspecified on non-digits. > Squeak, Pharo, Dolphin, VW, VAST, and Apple Smalltalk-80 > answer -1 for characters that are not digits (or ASCII letters), > which is unfortunate but consistent with Inside Smalltalk > which specifies this result for non-digits. > ST/X and GST raise an exception which is worse. > Digitalk ST/V documentation doesn't specify the result. > This selector is *much* easier to use safely if it > returns a 'large' (>= 36) value for non-digits." > > Let's compare three versions, the two I compared last time, > and the "version A" code I discussed before, which to my mind > is fairly readable. > > "Don't add slowness": 1 (normalised time) > "Trygve's code": 6.5 > "High level code": 30.6 (or 4.7 times slower than Trygve's) > > Here's the "High level code". > ^(aString allSatisfy: [:each | each isSpace or: [each isDigit]]) and: [ > |digitsReverse| > digitsReverse := (aString select: [:each | each isDigit]) reverse. > digitsReverse size > 1 and: [ > |evens odds evenSum oddSum| > odds := digitsReverse withIndexSelect: [:y :i | i odd]. > evens := digitsReverse withIndexSelect: [:x :i | i even]. > oddSum := odds detectSum: [:y | y digitValue]. > evenSum := evens detectSum: [:x | > #(0 2 4 6 8 1 3 5 7 9) at: x digitValue + 1]. > (oddSum + evenSum) \\ 10 = 0]] > > This is the kind of code I was recommending that Roelof write. > > As a rough guide, by counting traversals (including ones inside existing > methods), I'd expect the "high level" code to be at least 10 times slower > than the "no added slowness" code. > > We are in vehement agreement that there is a time to write high level > really obvious easily testable and debuggable code, and that's most > of the time, especially with programming exercises. > > I hope that we are also in agreement that factors of 30 (or even 6) > *can* be a serious problem. I mean, if I wanted something that slow, > I'd use Ruby. > > I hope we are also agreed that (with the exception of investigations > like this one) the time to hack on something to make it faster is AFTER > you have profiled it and determined that you have a problem. > > But I respectfully suggest that there is a difference taking slowness OUT > and simply not going out of your way to add slowness in the first place. > > I'd also like to remark that my preference for methods that traverse a > sequence exactly once has more to do with Smalltalk protocols than > with efficiency. If the only method I perform on an object is #do: > the method will work just as well for readable streams as for > collections. If the only method I perform on an object is #reverseDo: > the method will work just as well for Read[Write]Streams as for > SequenceReadableCollections, at least in my library. It's just like > trying to write #mean so that it works for Durations as well as Numbers. > > Oh heck, I suppose I should point out that much of the overheads in > this case could be eliminated by a Self-style compiler doing dynamic > inlining + loop fusion. There's no reason *in principle*, given enough > people, money, and time, that the differences couldn't be greatly > reduced in Pharo. > > On Tue, 5 May 2020 at 21:50, Trygve Reenskaug <trygver(a)ifi.uio.no> wrote: > > > Richard, > > Thank you for looking at the code. It is comforting to learn that the code > has been executed for a large number of examples without breaking. The code > is not primarily written for execution but for being read and checked by > the human end user. It would be nice if we could also check that it gave > the right answers, but I don't know how to do that. > > The first question is: Can a human domain expert read the code and sign > their name for its correctness? > > > When this is achieved, a programming expert will transcribe the first code > to a professional quality program. This time, the second code should be > reviewed by an independent programmer who signs their name for its correct > transcription from the first version. > > --Trygve > > PS: In his 1991 Turing Award Lecture, Tony Hoare said: "There are two ways > of constructing a software design: One way is to make it so simple that > there are obviously no deficiencies and the other is to make it so > complicated that there are no obvious deficiencies. The first method is far > more difficult." > > --Trygve > > On tirsdag.05.05.2020 04:41, Richard O'Keefe wrote: > > As a coding experiment, I adapted Trygve Reenskoug's code to my > Smalltalk compiler, put in my code slightly tweaked, and benchmarked > them on randomly generated data. > > Result: a factor of 6.3. > > In Squeak it was a factor of ten. > > I had not, in all honesty, expected it to to be so high. > > On Tue, 5 May 2020 at 02:00, Trygve Reenskaug <trygver(a)ifi.uio.no> wrote: > > A coding experiment. > Consider a Scrum development environment. Every programming team has an > end user as a member. > The team's task is to code a credit card validity check. > A first goal is that the user representative shall read the code and agree > that it is a correct rendering of their code checker: > > luhnTest: trialNumber > | s1 odd s2 even charValue reverse | > ----------------------------------------------- > " Luhn test according to Rosetta" > "Reverse the order of the digits in the number." > reverse := trialNumber reversed. > "Take the first, third, ... and every other odd digit in the reversed > digits and sum them to form the partial sum s1" > s1 := 0. > odd := true. > reverse do: > [:char | > odd > ifTrue: [ > s1 := s1 + char digitValue. > ]. > odd := odd not > ]. > "Taking the second, fourth ... and every other even digit in the reversed > digits: > Multiply each digit by two and sum the digits if the answer is greater > than nine to form partial sums for the even digits" > "The subtracting 9 gives the same answer. " > "Sum the partial sums of the even digits to form s2" > s2 := 0. > even := false. > reverse do: > [:char | > even > ifTrue: [ > charValue := char digitValue * 2. > charValue > 9 ifTrue: [charValue := charValue - 9]. > s2 := s2 + charValue > ]. > even := even not > ]. > "If s1 + s2 ends in zero then the original number is in the form of a > valid credit card number as verified by the Luhn test." > ^(s1 + s2) asString last = $0 > --------------------------------- > Once this step is completed, the next step will be to make the code right > without altering the algorithm (refactoring). The result should be readable > and follow the team's conventions. > > > P.S. code attached. > > > -- > > The essence of object orientation is that objects collaborate to achieve > a goal. > Trygve Reenskaug mailto: trygver(a)ifi.uio.no > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway Tel: (+47) 468 58 625 > > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > >

May 15, 2020

Re: [Pharo-users] Deleting images / saving as - in Pharo Launcher auncher

by CÃ©drick BÃ©ler

And thanks you for supporting it and describing it better :) This is an addition I hacked but I lost the code ^^ (was really hacks). Iâm pretty sure that would be easy to implement for Â« core dev Â» . Basically, this is another save as, maybe Â« save version Â» ? Then the "save as Â» should be deactivated in launcher probably. Cheers, CÃ©drick > Le 15 mai 2020 Ã 11:13, Tim Mackinnon <tim(a)testit.works> a Ã©crit : > > I find I do the same sort of precautionary measure (and probably would do it more if launcher supported this use case and helped me manage those snaphot images) - I view it a bit like how TimeMachine lets you see previous versions of files - yes the source code is versioned, but its just the useful execution state and window layouts that are handy to hold on to. Equally, I don't need too many of these images - and indeed want them to expire (but happy to manage that myself - its just a simple counter, or time snapshot that would make this very handy). > > Thanks for mentioning it Cedrick > > Tim > > On Fri, 15 May 2020, at 8:54 AM, CÃ©drick BÃ©ler wrote: >> Thanks for the explanation Christophe. >> >> The tree might be a good idea. >> >>> >>>> I actually changed once the "save as Â» in a Â« save checkpoint charly Â» where it saves a copy but still load the default name. Might be an option ? :) >>> >>> Â« Saves a copy Â» : do you mean you copy the full folder to another name ? >> >> I mean that when I Â« save as Â», I do it mainly because I know my next >> code evaluation could crash the image ^^. >> >> So basically, what I need is to save a copy of the image (timestamped >> eventually) but still using the original one. **So later, in case of >> crash, I can roll back to a previous backup**. >> >> That is far easier to implement I guess than the tree and that would be >> **very** useful to me at least ;-) >> >> >> >> Not sure, but I also think we should enforce by default to share the >> iceberg repo. For most people, top save sandwich, etc, it seems a >> better direction to me. This is optional right now but canât we change >> the default ? >> >> >> Cheers, >> >> CÃ©drick >> >> >>> >>> Cheers, >>> Christophe >> >> >> >

May 15, 2020

Re: [Pharo-users] Deleting images / saving as - in Pharo Launcher auncher

by Tim Mackinnon

I find I do the same sort of precautionary measure (and probably would do it more if launcher supported this use case and helped me manage those snaphot images) - I view it a bit like how TimeMachine lets you see previous versions of files - yes the source code is versioned, but its just the useful execution state and window layouts that are handy to hold on to. Equally, I don't need too many of these images - and indeed want them to expire (but happy to manage that myself - its just a simple counter, or time snapshot that would make this very handy). Thanks for mentioning it Cedrick Tim On Fri, 15 May 2020, at 8:54 AM, CÃ©drick BÃ©ler wrote: > Thanks for the explanation Christophe. > > The tree might be a good idea. > > > > >> I actually changed once the "save as Â» in a Â« save checkpoint charly Â» where it saves a copy but still load the default name. Might be an option ? :) > > > > Â« Saves a copy Â» : do you mean you copy the full folder to another name ? > > I mean that when I Â« save as Â», I do it mainly because I know my next > code evaluation could crash the image ^^. > > So basically, what I need is to save a copy of the image (timestamped > eventually) but still using the original one. **So later, in case of > crash, I can roll back to a previous backup**. > > That is far easier to implement I guess than the tree and that would be > **very** useful to me at least ;-) > > > > Not sure, but I also think we should enforce by default to share the > iceberg repo. For most people, top save sandwich, etc, it seems a > better direction to me. This is optional right now but canât we change > the default ? > > > Cheers, > > CÃ©drick > > > > > > Cheers, > > Christophe > > >

May 15, 2020

Re: Code completion in blocks (Pharo8)

by Davide Varvello

Hi Guillermo, I have tried Pharo9 and it works, so unfortunately is a issue of Pharo8 Thanks Davide Guillermo Polito wrote > Hi Davide, > > Iâm not sure if that works on Pharo8. Could you try quickly Pharo9 to see > if thatâs fixed there? > Iâve made a pass on the code completion there.. Donât know how difficult > it would be to back port it, I could give you the pointers if you want. > >> El 6 may 2020, a las 12:24, Davide Varvello via Pharo-users < > pharo-users@.pharo > > escribiÃ³: >> >> >> De: Davide Varvello < > varvello@ > > >> Asunto: Re: Code completion in blocks (Pharo8) >> Fecha: 6 de mayo de 2020, 12:24:46 CEST >> Para: > pharo-users@.pharo >> >> >> nobody? >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 15, 2020

Re: [Pharo-users] [ANN] Pharo Compendium

by CÃ©drick BÃ©ler

Hi Torsten, > > Hi CÃ©drick, > > The GitHub part is based on an open public GitHub HTTP query - which has some limits: > - it does not return private repos, only public ones > - it has a rate limit to not bring servers down > > Maybe there is a way to overcome these limits via authentication, yes. But most of my projects are > public - so for me this was not a problem yet. I tried with public ones (I donât think I have a private or maybe because I tried once). It seems it was related to my authentification problem. What I did wad adding the Â« pharo Â» tag to some project after I loaded and tried Compendium. So the crawler hadnât seen them. Browsing the code, I managed to reset the cache. And then, when typing my GitHub name (cdrick65), it started downloading stuff but wasnât showing anything after. Iâll try again in a new image. > And the initial idea of Compendium is to find public > resources available to all users - not private ones available to single ones. > > If time permits I might look into this ... but not now. No hurry ;), already a great tool to load packages ! I love it. What would be great is to access a summary info (the readme.md ?) and show for instance in the spotter search (but no hurry too). And as time allows, Iâll surely try to hack it because possibilities are endless :) Cheers, CÃ©drick > > Bye > T. > > Gesendet: Donnerstag, 14. Mai 2020 um 13:02 Uhr > Von: "CÃ©drick BÃ©ler" <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>> > An: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > Betreff: Re: [Pharo-users] [ANN] Pharo Compendium > > Really great tool Torsten :) > > I tagged some of my repo to test. I reseted the stores because they wasnât showing. It seems to load but then when querying in spotter, I got an error message because of non authentification. > > > I went in in the (iceberg) settings, checked then unchecked the default RSA keys directory (by the way is it a know bug or is it just me ?). > > It worked after, I mean no error when querying spotter. > > Still I donât see my projects. Iâll try later but if you have an idea... > > > Cheers, > CÃ©drick > > Le 12 mai 2020 Ã 16:35, Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>[mailto:astares@gmx.de <mailto:astares@gmx.de>]> a Ã©crit : > > Hi Sven, > > I added spotter search now. I prefixed the github spotter entries additionally with the user name (owner). > This way you will be able to quickly find tagged public projects by keying in the project and/or username. > > See attached picture for an example. > > Catalog loading is possible via spotter too. > > Have fun > T. > Gesendet: Mittwoch, 06. Mai 2020 um 14:24 Uhr > Von: "Sven Van Caekenberghe" <sven(a)stfx.eu <mailto:sven@stfx.eu>[mailto:sven@stfx.eu <mailto:sven@stfx.eu>]> > An: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>[mailto:pharo-users@lists.pharo.org <mailto:pharo-users@lists.pharo.org>]> > Betreff: Re: [Pharo-users] [ANN] Pharo Compendium > > Great work, Torsten, works like a charm ! > > Since all Github projects have a README.md maybe that could be used as well, it will certainly contain more information. > > Most projects have several keyswords as well, that could be useful to show. > > Also, why not add a 'clone & metacello install baseline of' command ? > > Another idea: allow spotter searching of the pharo compendium entries ? > > Sven > On 2 May 2020, at 22:34, Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>[mailto:astares@gmx.de <mailto:astares@gmx.de>]> wrote: > > Hi, > > time flows and Pharo-Project is improving on all ends since its inception in 2008. As you know over time for the code project hosting we used > SqueakSource, SS3 repos and other and later switched to SmalltalkHub available on http://smalltalkhub.com[http://smalltalkhub.com <http://smalltalkhub.com[http://smalltalkhub.com>]. > Starting with Iceberg in Pharo 6 many community projects are now hosted elsewhere - most of them moved to GitHub. Pharo's git support allows > also for GitLab, BitBucket and other git hosting services. > > I still think easy and quick accessibility to external (re)sources directly from the image is key - especially for new users who often get lost > among all the various things that are available. Back in 2013 I therefore provided a small tool called ConfigBrowser as a replacement for > MetacelloConfigurationBrowser to easily load Metacello configs directly into Pharo. > > Later we improved quick loading with a primary tool called "Catalog" written by Esteban. Catalog is indexing every 24 hours all configs within > specific meta-repositories on SmalltalkHub (per Pharo version) like > > http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo80[http://www.smallta… <http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo80[http://www.smallta…>] > > to automatically build > > http://catalog.pharo.org/[http://catalog.pharo.org/ <http://catalog.pharo.org/[http://catalog.pharo.org/>] > > and also a JSON source > > http://catalog.pharo.org/catalog/json[http://catalog.pharo.org/catalog/json <http://catalog.pharo.org/catalog/json[http://catalog.pharo.org/catalog/json>] > > The last one feeds the catalog browser and catalog spotter search within the Pharo image. > > So Catalog helped us and especially new Pharo users to find what is available as external project or package. Unfortunately some package maintainers > are too lazy and do not maintain their configs over old and new Pharo versions. Also SmalltalkHub.com <http://smalltalkhub.com/>[http://SmalltalkHub.com <http://smalltalkhub.com/>] is now seen as legacy and will only be available > in a read only mode or as a browseable archive soon. > > So we have to think about others steps beyond Catalog and (triggered by a recent discussion on Discord) I started now a simple tool that helped me > finding all GitHub projects marked with "pharo" as GitHub topic. I additionally also added previous catalog loading. More sources could be added > as well as some kind of custom stores/plugins. Maybe this tool could be the base for a future replacement of the catalog tool. > > Long story short - let me introduce "Pharo Compendium": > > Compendium is a new UI tool to list, browse and load Pharo artefacts from the web like: > > - GitHub Projects > - Catalog Projects > > and other > > By default there are two plugin packages available for GitHub and Catalog - but you can implement own ones easily to connect to other sources > on the web. Compendium is available on: > > https://github.com/astares/Pharo-Compendium[https://github.com/astares/Phar… <https://github.com/astares/Pharo-Compendium[https://github.com/astares/Phar…>] > > It is implemented using the new Spec2 UI framework - so you need a recent Pharo 9 image to give it a try. Just run: > > Metacello new > repository: 'github://astares/Pharo-Compendium/src'; > baseline: 'Compendium'; > load > > to load the tool. Then go to "Tools" -> "Compendium Browser". Attached is a screenshot demoing the primary functionality. > > If you want your GitHub project to be listed in the tool you simply need to add the topic "pharo" to the GitHub repository on the GitHub webpage. > > Feel free to comment or help improving the tool by sending PR's. > > Thx > T. (aka astares) > > > <compendium.png> > > <Compendium_Spotter.jpg>

May 15, 2020

Re: [Pharo-users] Deleting images / saving as - in Pharo Launcher auncher

by CÃ©drick BÃ©ler

Thanks for the explanation Christophe. The tree might be a good idea. > >> I actually changed once the "save as Â» in a Â« save checkpoint charly Â» where it saves a copy but still load the default name. Might be an option ? :) > > Â« Saves a copy Â» : do you mean you copy the full folder to another name ? I mean that when I Â« save as Â», I do it mainly because I know my next code evaluation could crash the image ^^. So basically, what I need is to save a copy of the image (timestamped eventually) but still using the original one. **So later, in case of crash, I can roll back to a previous backup**. That is far easier to implement I guess than the tree and that would be **very** useful to me at least ;-) Not sure, but I also think we should enforce by default to share the iceberg repo. For most people, top save sandwich, etc, it seems a better direction to me. This is optional right now but canât we change the default ? Cheers, CÃ©drick > > Cheers, > Christophe

May 15, 2020

Re: [Pharo-users] Deleting images / saving as - in Pharo Launcher auncher

by StÃ©phane Ducasse

> On 14 May 2020, at 23:20, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Hi CÃ©drick, > >> Le 7 mai 2020 Ã 08:24, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> a Ã©crit : >> >> Hi Christophe, >> >> >> This version is definitely cooler :) > > Thanks > >> I just wander as for the previous version why deleting image can take some time, whereas itâs quick to delete the image repository. Is it normal ? > > In Pharo, deleting files is slow because Pharo visits all the files to delete to check if there are file descriptors opened on these files to close them. > I think it is something that could be improved. In many situations, you know you do not have descriptors on these files and we could have a method to delete without doing the check, just the system call, without visiting the tree. + 1 Yes we should introduce a massiveFolder delete. > >> Another thing that might help my way of doing things. I like to "save as" the image so as to have a quick check point, and the launcher is not Â« friendly Â» with renaming as it loads the default image. >> >> Any idea on how to integrate that ? Maybe having a list of images that pops-up ? > > For this feature, I have no good idea for now. > I had in mind to use a tree instead of a list of images. You could expand if there are more than one image and see other images in the folder. > The problem is for the metadata file: we could assume that other images should use the same metadata as the core image and use them to run the image. (For now, the metadata filename is the same for all images). > >> I actually changed once the "save as Â» in a Â« save checkpoint charly Â» where it saves a copy but still load the default name. Might be an option ? :) > > Â« Saves a copy Â» : do you mean you copy the full folder to another name ? > > Cheers, > Christophe -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

May 15, 2020

Re: [Pharo-users] Covid-19 Tracker with PharoJS

by Guillermo Polito

Itâs cool! > El 14 may 2020, a las 17:37, Noury Bouraqadi <bouraqadi(a)gmail.com> escribiÃ³: > > Hi, > > Dave Mason did implement a COVID-19 tracker with PharoJS. > https://covid.cs.ryerson.ca/compare/ <https://covid.cs.ryerson.ca/compare/> > > Noury

May 15, 2020

Re: [Pharo-users] git and Pharo new book...

by StÃ©phane Ducasse

Thanks! S > On 15 May 2020, at 03:50, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > I already start to send PRs to fix typos. > > > > On Thu, May 14, 2020 at 9:55 PM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > if you want to contribute to a chapter on other than github solutions. > I would be happy to help editing such chapter. > > If you want to you can do a PR with a chapter. > > S > >> On 14 May 2020, at 03:22, Pierce Ng <pierce(a)samadhiweb.com <mailto:pierce@samadhiweb.com>> wrote: >> >> On Wed, May 13, 2020 at 11:07:00AM -0500, Offray Vladimir Luna CÃ¡rdenas wrote: >>> This is perfect timing, as I have started to slowly migrate my own repos >>> from SmalltalkHub to a simple, self hosted and self contained Gitea[1] >> >> Hi Offray, >> >> I run Gitea on a Raspberry Pi at home. I have a couple of scripts that >> back up the Gitea data, encrypt the backup with GPG, then uploads >> somewhere. Happy to share if you want them. >> >> On the topic, Iceberg works fine with Gitea. My SOP as follows: >> >> - create repo using Gitea web interface >> - using command line, clone locally via ssh >> - using command line, 'git remote add ...' >> >> Then in Iceberg use the local clone. >> >> Pierce >> >> > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <http://www.pharo.org/> > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > > > -- > Serge Stinckwicâhâ > https://twitter.com/SergeStinckwich <https://twitter.com/SergeStinckwich> > â -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

May 15, 2020

Re: [Pharo-users] git and Pharo new book...

by Serge Stinckwich

I already start to send PRs to fix typos. On Thu, May 14, 2020 at 9:55 PM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > if you want to contribute to a chapter on other than github solutions. > I would be happy to help editing such chapter. > > If you want to you can do a PR with a chapter. > > S > > On 14 May 2020, at 03:22, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > On Wed, May 13, 2020 at 11:07:00AM -0500, Offray Vladimir Luna CÃ¡rdenas > wrote: > > This is perfect timing, as I have started to slowly migrate my own repos > from SmalltalkHub to a simple, self hosted and self contained Gitea[1] > > > Hi Offray, > > I run Gitea on a Raspberry Pi at home. I have a couple of scripts that > back up the Gitea data, encrypt the backup with GPG, then uploads > somewhere. Happy to share if you want them. > > On the topic, Iceberg works fine with Gitea. My SOP as follows: > > - create repo using Gitea web interface > - using command line, clone locally via ssh > - using command line, 'git remote add ...' > > Then in Iceberg use the local clone. > > Pierce > > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > -- Serge Stinckwic âhâ https://twitter.com/SergeStinckwich â

May 15, 2020