August 2017 - Pharo-users - lists.pharo.org

Checking in on source/dependency management

by sergio ruiz

Hi, all.. I am just checking in on source and dependency management.Â I have been using Pharo 6 for a bit now, and i know that there has been a lot of talk about going to bit for source code management.Â I am wondering how far along that is, and if there is a package we can start using to work through that. I am also wondering if metacello is still the dependency management system of choice. I was using the GUI tool in for package management in pharo 5, but i was having issues with getting my project mangled. Is there a new current view on how all this should be done? Thanks! ---- peace, sergio photographer, journalist, visionary Public Key:Â http://bit.ly/29z9fG0 #BitMessageÂ BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Aug. 9, 2017

Re: [Pharo-users] Stylistic question: private helper vs extension method?

by Herby VojÄÃk

Esteban A. Maringolo wrote: > 2017-08-08 17:49 GMT-03:00 Esteban Lorenzano<estebanlm(a)gmail.com>: >> Extension. Helpers are for javaers. > > Extensions are concise, and right to the point, but as long as they > stay in your private image or prove of value to everybody else both in > function and selector naming. > > My guides are: > A. If it's your image, extend Dictionary, Object or whatever you want. > It's your mess, your image, your rules.\ True. > B. If you're going to share the code with others (as a library), then > you should check whether the selectors clash with existing ones, or > have "side effects". > C. If it's going in the "core" image, then the selector should be well > thought, having broad application semantics and coherence with the > existing selectors, like the current #at:ifAbsent:, #at:ifPresent:, > etc. > > In this case I'd go for something like: > > Dictionary>>#at: key ifPresentPut: aBlock Never imagined it should be at:ifPresentPut:. Not clear at the first sight, but undobutedly it is the best pick, on the second one. > "Lookup the given key in the receiver. If it is present, update it > with the value of evaluating the given block with the value associated > with the key. Otherwise, answer nil." > > ^self at: key ifPresent: [ :object | self at: key put: (aBlock > cull: object) ] Well, if it is seen as a thing of value, you or someone can add it to pharo7 (I probably can not, not having and not wanting to have github account). Maybe for Array / String as well. > And you'd call it like: > responsePayload at: each ifPresentPut: [ :uuid | uuid asString ]. In my case, `responsePayload at: each ifPresentPut: #asString` probably. I don't care for a bit of perf hit (I like Symbol >> value:, during Amber development I often do `Smalltalk packages do: #commit` to commit everything and see what changed in git diff). > or: > responsePayload at: each ifPresentPut: [ 'FooBaz' ]. > > > Regards, > > Esteban A. Maringolo Thanks, Herby

Aug. 9, 2017

Re: [Pharo-users] API docs as HTML

by Offray Vladimir Luna CÃ¡rdenas

Thanks Esteban, Any documentation to start with? How can I install this? Cheers, Offray On 09/08/17 10:08, Esteban Lorenzano wrote: > this was the webdoc project (made originally by Camillo Bruni) > > https://github.com/estebanlm/pharo-webdoc > > butâ¦ you will need to massage it a bit to make it work :) > also, Guille made a simplification some time agoâ¦ he will know where > it is or whatâs his status. > > Esteban > >> On 9 Aug 2017, at 16:41, Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >> >> Hi, >> >> For the JOSS (Journal of Open Source Software) I need to add to a >> package documentation the API documentation as an external file >> (hopefully in HTML). So I would like to export the source code in a way >> that can be used as API documentation. I remember that some API >> documentation about Smalltalk/Pharo can be found online, but I don't >> know how to produce such documents. Any pointers to explore? >> >> Cheers, >> >> Offray >> >> >> >

Aug. 9, 2017

Re: [Pharo-users] API docs as HTML

by Esteban Lorenzano

this was the webdoc project (made originally by Camillo Bruni) https://github.com/estebanlm/pharo-webdoc <https://github.com/estebanlm/pharo-webdoc> butâ¦ you will need to massage it a bit to make it work :) also, Guille made a simplification some time agoâ¦ he will know where it is or whatâs his status. Esteban > On 9 Aug 2017, at 16:41, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > For the JOSS (Journal of Open Source Software) I need to add to a > package documentation the API documentation as an external file > (hopefully in HTML). So I would like to export the source code in a way > that can be used as API documentation. I remember that some API > documentation about Smalltalk/Pharo can be found online, but I don't > know how to produce such documents. Any pointers to explore? > > Cheers, > > Offray > > >

Aug. 9, 2017

API docs as HTML

by Offray Vladimir Luna CÃ¡rdenas

Hi, For the JOSS (Journal of Open Source Software) I need to add to a package documentation the API documentation as an external file (hopefully in HTML). So I would like to export the source code in a way that can be used as API documentation. I remember that some API documentation about Smalltalk/Pharo can be found online, but I don't know how to produce such documents. Any pointers to explore? Cheers, Offray

Aug. 9, 2017

Adding the checksum of a file to another (was Re: Problems verifying the cryptographic signature of a file.)

by Offray Vladimir Luna CÃ¡rdenas

Hi, After talking with Peter at discord, I think that my question is clearer. I have two procedures. One that writes a file ( GrafoscopioNotebook>>saveToFile: ) and other that returns the SHA1 checksum of that file ( GrafoscopioNotebook>>checksum ). What I would like to do is to add the checksum of the saved file to another file, which is important also for some tests. That implies that I need to know that the writing procedure ( #saveToFile: ) has ended before running the checksum. How can I ensure that? Need I to create some announcement in the #saveToFile: method to use it into others that need to be aware of the ending of the first one? Any literature of resource to check (I have browse Blocks and and Exeptions chapter of PBE2, but still don't find the proper message to work with this, and #ensure: and #curtail seem not the proper choice). Cheers, Offray On 31/07/17 12:35, Esteban A. Maringolo wrote: > How do check the signature of a file? > > I guess you must ensure the file creation is complete as well as its > digital signing. So if these steps are done asynchronously you should > synchronize them by means of a semaphore or similar. > > Regards! > > Esteban A. Maringolo > > > 2017-07-31 14:11 GMT-03:00 Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com>: >> Hi, >> >> I'm having problems to verify the cryptographic signature of a file. It >> seems that the test is running, some times, while the file is being created, >> and some times when the file writing is finished (which is my purpose). How >> can I run the cryptographic signature verification only after the writing of >> the file is finished? I imagine that is something related with jobs and >> completion, but I don't know where to look for, specifically. >> >> Any hints and suggestions are welcomed. >> >> Cheers, >> >> Offray >

Aug. 9, 2017

Re: [Pharo-users] Stylistic question: private helper vs extension method?

by Esteban A. Maringolo

2017-08-08 17:49 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Extension. Helpers are for javaers. Extensions are concise, and right to the point, but as long as they stay in your private image or prove of value to everybody else both in function and selector naming. My guides are: A. If it's your image, extend Dictionary, Object or whatever you want. It's your mess, your image, your rules. B. If you're going to share the code with others (as a library), then you should check whether the selectors clash with existing ones, or have "side effects". C. If it's going in the "core" image, then the selector should be well thought, having broad application semantics and coherence with the existing selectors, like the current #at:ifAbsent:, #at:ifPresent:, etc. In this case I'd go for something like: Dictionary>>#at: key ifPresentPut: aBlock "Lookup the given key in the receiver. If it is present, update it with the value of evaluating the given block with the value associated with the key. Otherwise, answer nil." ^self at: key ifPresent: [ :object | self at: key put: (aBlock cull: object) ] And you'd call it like: responsePayload at: each ifPresentPut: [ :uuid | uuid asString ]. or: responsePayload at: each ifPresentPut: [ 'FooBaz' ]. Regards, Esteban A. Maringolo

Aug. 9, 2017

Re: [Pharo-users] gtInspector override default select behavior

by Andrei Chis

On Mon, Aug 7, 2017 at 11:11 PM, Evan Donahue <emdonahu(a)gmail.com> wrote: > Perfect. > > Do you know if these methods are systematically documented anywhere? I feel > like if I understood Glamour better these things might be more obvious, but > I can never manage to infer the gtInspector calls from the Glamour docs. > The best way to learn about the inspector is by browsing the glamour examples (GLMBasicExamples open) and the inspector presentations from the image (Inspect the class GTInspector and switch to the Extensions tab). Also themoosebook.org has some documentation about glamour. Cheers, Andrei > > Thanks. > > > > -- > View this message in context: http://forum.world.st/ > gtInspector-override-default-select-behavior-tp4959037p4959141.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 9, 2017

Re: [Pharo-users] Stylistic question: private helper vs extension method?

by Henrik Johansen

> On 8 Aug 2017, at 22:39 , Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > Hello! > > I've got this portion in my delegate: > > requestPayload ifNotNil: [ uuidKeys do: [ :each | > requestPayload at: each ifPresent: [ :s | requestPayload at: each put: (UUID fromString: s) ] ] ]. > responsePayload := self towergame clientSync: requestPayload. > responsePayload ifNotNil: [ uuidKeys do: [ :each | > responsePayload at: each ifPresent: [ :uuid | responsePayload at: each put: uuid asString ] ] ]. > > Now I would gladly use something like Dictionary >> at:ifPresentTransform: aBlock. But it is not present, so I have two choices: > > 1. Add it as extension method, but then it may clash if someone else has similar idea. > 2. Add private helper TowergameDelegate >> dict:at:ifPresentTransform:, which is longer and needs additional self receiver. > > Which is preferable? > > Herby Following existing convention, an extension would be named #at:ifPresentPut: I wonder though, wouldn't it be simpler to just put(UUID fromString: s) in the first place, and convert (dict at: uuidKey) in the accesses that needs it (or vice versa)? Shifting the class of values like this seems like it could be a nightmare to debug and/or extend in the future remaining confident all uses will occur in the correct/expected order... Cheers, Henry

Aug. 9, 2017

Re: [Pharo-users] PetitParser: Parse X as long as it's not Y

by PBKResearch

Sean One extra point. You may need to post-process the parse to get what you want. In the 'restricted' line, if you don't have a #gen then 'gen negate' will have succeeded and will generate its own node in the parse - in your example of ' Paul' as input it will be $P. Assuming you don't want this (!), you can add ==> [:nodes| nodes second] to the definition of restricted. I had realized this after I posted on Sunday, as well as the fact that I had put the anded elements in the wrong order, but I didn't want to generate a stream of supplementaries. HTH Peter -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sean P. DeNigris Sent: 09 August 2017 03:41 To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] PetitParser: Parse X as long as it's not Y Peter Kenny wrote > This seems to be what the PPAndParser is designed for. Thanks for the pointer, Peter! I finally figured it out based on your example. To get more concrete, I'm trying to parse a name, where the end of the input might be an optional middle name, followed by an optional generational (e.g. 'Paul III'). What I think the restricted line says is: "peek to make sure we don't have a #gen, then try to parse an #identifier". Interestingly the order is important. If the peek and identifier are reversed, it tries to peek after the identifier, causing an error when there is only a middle name (i.e. no more input). identifier := #letter asParser plus flatten. gen := 'Jr' asParser / 'Sr' asParser. restricted := gen negate and, identifier. parser := ((#space asParser, restricted) optional, (#space asParser, gen) optional) end. parser parse: ' Paul Jr'. parser parse: ' Paul'. parser parse: ' Jr'. This really had me baffled. Thanks again!! ----- Cheers, Sean -- View this message in context: http://forum.world.st/PetitParser-Parse-X-as-long-as-it-s-not-Y-tp4958895p49 59268.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 9, 2017