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

Re: [Pharo-users] spotting methods with TODO, FIXME, etc. comments?

by Hilaire

Hi Raffaello, You can annotate your methods with a pragma, for example <workInProgress>, then from the Finder tool (WorldMenu>Tools>Finder), you search for pragma: In the left text field, input workInProgress, then in the drop down list at the right, select Pragmas. Hilaire Le 01/03/2017 Ã 18:53, Raffaello Giulietti a Ã©crit : > Hi community, > > many IDEs for other language usually offer a way to annotate methods > with special comments like "TODO ...", "FIXME ...". Such methods can > then be later retrieved easily in task lists and selected by simple clicks. > > Is there something similar in Pharo? > > Thanks > -- Dr. Geo http://drgeo.eu

March 1, 2017

spotting methods with TODO, FIXME, etc. comments?

by Raffaello Giulietti

Hi community, many IDEs for other language usually offer a way to annotate methods with special comments like "TODO ...", "FIXME ...". Such methods can then be later retrieved easily in task lists and selected by simple clicks. Is there something similar in Pharo? Thanks

March 1, 2017

Pharo Association

by Jimmie Houchin

Hello, I am looking into the Pharo Association. I looked at the Contribute page, http://pharo.org/contribute and saw the links to BountySource. One of them had $9 monthly being a Gold Membership Pharo Association. I do not see this as an option if you do Join on the Pharo Association Join Us page, https://association.pharo.org/join-us . I do not know which option is most favorable for or least expensive to the Pharo Association. I also do not see what payment methods are available on the Pharo Association pages. BountySource I know my options. From the BountySource page I do not know how this connects me to the PharoAssociation. If all things are equal, I would assume do BountySource, I can start a monthly cash flow immediately. It would also be nice to know if doing BountySource that is always an option to levels other than the set levels but you only get the benefits of the highest level you contribute at. For example if I wanted to do $15 a month instead of $9, or even a simply $10 instead of $9. or .... I think this could be by instead of saying $9 a month, express it as minimum of $9 a month. Or what is appropriate for each level. If BountySource is more expensive on the Association's end. I would prefer to do whatever payment options are on the Association site. But it would be nice to know what those are before I begin to complete the forms. Thanks for any information on the process so that I can begin to contribute to Pharo. Jimmie Houchin

March 1, 2017

Re: [Pharo-users] Problems with PipeableOSProcess

by Silas Berger

Hi Dave Okay, great, thanks for your pointers. I found the error stream. The error says /bin/sh: /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/tools/mac/parsecit/bin/citeExtract.pl -m extract_all /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/examplePDFsFromList/Ardi97aSchemeTeaching.pdf.txt: No such file or directory Iâll have to investigate on why this happens for one .txt file, but not for the other one (Ache00aScriptingCoordStyles.pdf.txt) in the same folder, even though I canât see any notable differences (like spaces, quotes, â¦) between the two filenamesâ¦ Thanks again for your help! Silas Hi Silas, I am travelling and cannot help much right now, but to answer one of your questions - yes, you can inspect errors in a PipeableOSProcess. It has an "error pipeline stream" that will contain any output from the stderr stream of the process. It also has a process proxy for the actual external OS process, which will show exit status for the process. In your case that probably will not help much, because you will just see exit status for the /bin/shell that you ran, not for the process that ran your perl script. Nevertheless it may be interesting to check it. One possible source of problems in a case like this is command line parsing. The command line that you pass from Pharo may get parsed differently than a normal bash terminal shell, especially with respect to quoting strings. Also, you refer to an empty string, which certainly sounds like it is related to the problem, although I cannot say why. Dave > Hi everyone, > > > > I'm currently experiencing problems with PipeableOSProcess. I'm using a > command to run a third party tool, which reads a txt file and returns an > XML > string. In my collection, this works fine for about 75 out of 100 txt > files, > but fails on the remaining 25 ones. However, the tool itself doesn't fail. > It works fine, if I issue the commands directly from a Terminal. > > > > Here's an example of a command string that works: > > /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/tools/mac/ > parsecit/bin/citeExtract.pl -m extract_all > /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/examplePDF > sFromList/Ache00aScriptingCoordStyles.pdf.txt > > > > And here's an example of one that doesn't work. > > /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/tools/mac/ > parsecit/bin/citeExtract.pl -m extract_all > /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/examplePDF > sFromList/Ardi97aSchemeTeaching.pdf.txt > > > > This is how I apply these commands through PipeableOSProcess: > > > >Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â xml := (PipeableOSProcess command: cmdString) output. > > > > For the first command, xml is a large XML string, for the second command, > it's just an empty string. As I've mentioned above, both commands work > just > fine in a Terminal. They both produce a correct XML string. > > > > Does anyone have an idea why this could be the case? Is there a way to > access errors in the PipeableOSProcess, if there are any? Is there a > better > way to issue terminal commands from Pharo? > > > > Thanks for your help! > > > > Cheers, > > Silas > >

March 1, 2017

Re: [Pharo-users] Problems with PipeableOSProcess

by David T. Lewis

Hi Silas, I am travelling and cannot help much right now, but to answer one of your questions - yes, you can inspect errors in a PipeableOSProcess. It has an "error pipeline stream" that will contain any output from the stderr stream of the process. It also has a process proxy for the actual external OS process, which will show exit status for the process. In your case that probably will not help much, because you will just see exit status for the /bin/shell that you ran, not for the process that ran your perl script. Nevertheless it may be interesting to check it. One possible source of problems in a case like this is command line parsing. The command line that you pass from Pharo may get parsed differently than a normal bash terminal shell, especially with respect to quoting strings. Also, you refer to an empty string, which certainly sounds like it is related to the problem, although I cannot say why. Dave > Hi everyone, > > > > I'm currently experiencing problems with PipeableOSProcess. I'm using a > command to run a third party tool, which reads a txt file and returns an > XML > string. In my collection, this works fine for about 75 out of 100 txt > files, > but fails on the remaining 25 ones. However, the tool itself doesn't fail. > It works fine, if I issue the commands directly from a Terminal. > > > > Here's an example of a command string that works: > > /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/tools/mac/ > parsecit/bin/citeExtract.pl -m extract_all > /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/examplePDF > sFromList/Ache00aScriptingCoordStyles.pdf.txt > > > > And here's an example of one that doesn't work. > > /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/tools/mac/ > parsecit/bin/citeExtract.pl -m extract_all > /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/examplePDF > sFromList/Ardi97aSchemeTeaching.pdf.txt > > > > This is how I apply these commands through PipeableOSProcess: > > > > xml := (PipeableOSProcess command: cmdString) output. > > > > For the first command, xml is a large XML string, for the second command, > it's just an empty string. As I've mentioned above, both commands work > just > fine in a Terminal. They both produce a correct XML string. > > > > Does anyone have an idea why this could be the case? Is there a way to > access errors in the PipeableOSProcess, if there are any? Is there a > better > way to issue terminal commands from Pharo? > > > > Thanks for your help! > > > > Cheers, > > Silas > >

March 1, 2017

Voyage and Scaled decimal

by Hilaire

Hi, It looks like Voyage, or Mongo, had a hard time with scaled decimal. I have an "Integer too large" error. Error: Integer too large: 1463035760746279168444519882918332074180871992424069768653697095674502345263300751487851490491702061753873077385550224188721036945253521387 May be at some time I will use float for efficiency, but in the mean time I would like to postpone optimisation and persist exact numeric value when possible. Hilaire -- Dr. Geo http://drgeo.eu

March 1, 2017

Re: [Pharo-users] Crash in Athens

by Igor Stasenko

On 1 March 2017 at 05:42, Alexander Samoylovich <samoylovich(a)gmail.com> wrote: > Thanks everybody for the explanation. > > I tried to apply Igor's suggestion. I allocate an offscreen surface 1 row > larger than needed > and when converting discard one row. > > The code looks more stable now. The test was up for about 30 minutes > before crashing instead of 1 minute before the fix. > Is it the right code change or just a coincidence? > > > AthensCairoSurface>>asForm > > > "create a form and copy an image data there" > > self checkSession. > > self flush. > > ^ Form extent: (self width@self height) - (0@1) depth: 32 bits: id > > no, it isn't . This is how it supposed to be there. But the problem is when you using surfaces for bitmaps in Cairo itself, you're screwed since AthensCairoSurface purposedly makes it 1 row taller, while for texture you want it to contain exact height, else you'll obviously have artifacts. :( So, the point is: if you creating a surface that will be used by bitblt (asForm), then you should allocate 1 extra row, else you shouldn't.. And there's no workaround to match such behavior in single class, since it doesn't knows what it will be used for :( > > On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Tx igor I added >> >> https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of- >> AthensCairoSurfaceForm >> >> On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >>> and i was dealing with it by adding 1 extra line to cairo surface, >>> but reporting 1 less to Form. Like so, bitblt still reads past the >>> allowed size, but it is safe, because there are unused bit(s). >>> >>> On 27 February 2017 at 20:31, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> >>>> >>>> On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm(a)gmail.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> the problem wit Ronieâs fix is that (as he says) you are copying >>>>> another time the surface, before passing it to the VM (who makes >>>>> yet-another-copy) so this is not optimalâ¦ and you can see it when running >>>>> the Tiger demo: there are a lot of pauses. >>>>> So I would prefer the other approach he suggests: >>>>> >>>>> Form subclass: #AthensCairoSurfaceForm >>>>> instanceVariableNames: 'surface' >>>>> classVariableNames: '' >>>>> package: 'Athens-Cairo' >>>>> >>>>> AthensCairoSurfaceForm>>surface >>>>> ^ surface >>>>> >>>>> AthensCairoSurfaceForm>>surface: anObject >>>>> surface := anObject >>>>> >>>>> AthensCairoSurface>>asForm >>>>> "create a form and copy an image data there" >>>>> self checkSession. >>>>> self flush. >>>>> ^ (AthensCairoSurfaceForm extent: (self width@self height) >>>>> depth: 32 bits: id) >>>>> surface: self; >>>>> yourself >>>>> >>>>> that seems to work. Can you try and see? >>>>> >>>>> >>>> Btw, remember the culprit there , that you must have extra word in >>>> trailing buffer space, >>>> this is because bit-blt using read-ahead . Which is OK for objects >>>> located in object memory, >>>> since there are always something past the last object (unallocated >>>> space), >>>> but not so ok for buffers allocated by malloc (such as cairo surface >>>> bitmap), and so, >>>> if you read even a single byte past it, you get protection fault. >>>> >>>> >>>>> Esteban >>>>> >>>>> > On 24 Feb 2017, at 15:47, stepharong <stepharong(a)free.fr> wrote: >>>>> > >>>>> > Hi alex >>>>> > >>>>> > can you try the fix of ronie and let us know if it makes roassal >>>>> more stable? >>>>> > >>>>> > Stef >>>>> > >>>>> >> Dear Alexander, >>>>> >> >>>>> >> Sine the new FFI of Pharo, using Athens has become unreliable. This >>>>> is a pity, but fixing this is not trivial at all (we have been trying for >>>>> years). >>>>> >> >>>>> >> What exactly are you doing with Athens? >>>>> >> >>>>> >> Alexandre >>>>> >> >>>>> >> >>>>> >>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich < >>>>> samoylovich(a)gmail.com> wrote: >>>>> >>> >>>>> >>> Hello >>>>> >>> >>>>> >>> I am writing graphic demo programs using Athens on Mac Sierra. >>>>> >>> Time by time Pharo VM crashes. Programs not using Athens work >>>>> reliably. >>>>> >>> I believe the behavior is reproducible. >>>>> >>> How should I report a bug? >>>>> >>> >>>>> >>> Alex >>>>> >> >>>>> > >>>>> > >>>>> > -- >>>>> > Using Opera's mail client: http://www.opera.com/mail/ >>>>> > >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > -- Best regards, Igor Stasenko.

March 1, 2017

Re: [Pharo-users] Problems with PipeableOSProcess

by Ben Coman

On Wed, Mar 1, 2017 at 8:47 PM, Silas Berger <silas.berger(a)students.unibe.ch> wrote: > > Hi everyone, > > > > Iâm currently experiencing problems with PipeableOSProcess. Iâm using a command to run a third party tool, which reads a txt file and returns an XML string. In my collection, this works fine for about 75 out of 100 txt files, but fails on the remaining 25 ones. However, the tool itself doesnât fail. It works fine, if I issue the commands directly from a Terminal. > > > > Hereâs an example of a command string that works: > > /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/tools/mac/parsecit/bin/citeExtract.pl -m extract_all /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/examplePDFsFromList/Ache00aScriptingCoordStyles.pdf.txt > > > > And hereâs an example of one that doesnât work. > > /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/tools/mac/parsecit/bin/citeExtract.pl -m extract_all /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/examplePDFsFromList/Ardi97aSchemeTeaching.pdf.txt > > > > This is how I apply these commands through PipeableOSProcess: > > > > xml := (PipeableOSProcess command: cmdString) output. > > > > For the first command, xml is a large XML string, for the second command, itâs just an empty string. Sorry I don't know the answers your seek - but just to clarify something. How significant is that empty string return? cheers -ben

March 1, 2017

Re: [Pharo-users] Proof of Concept: FileTree and Fossil

by Thierry Goubier

2017-03-01 13:15 GMT+01:00 Pierce Ng <pierce(a)samadhiweb.com>: > On Tue, Feb 28, 2017 at 04:23:12PM +0100, Thierry Goubier wrote: > > 2017-02-28 1:19 GMT+01:00 Pierce Ng <pierce(a)samadhiweb.com>: > > > I have written a simple integration of FileTree with Fossil to avoid > the > > Congratulations! This was one of my objectives with GitFileTree: open up > > the Pharo infrastructure to other DVCS such as Fossil. > > And indeed runOSSubprocessFossilCommand is basically > runOSSubprocessGitCommand, > so thank you for GitFileTree. > > I've only implemented #basicStoreVersion: and it is simply this: > > basicStoreVersion: aVersion > super basicStoreVersion: aVersion > (MCFossil new repoDir: self directory fullName) > addRemove; > commit: aVersion info message > > The last 3 lines is of course just the Smalltalk way of saying > "fossil addremove; fossil commit ..." > > Currently that's all it does. > Great! > > > > How does Fossil handles merging the FileTree format? > > Just to be sure I get your question, do you mean whether FossilFileTree > sees > the changes if I edit the .st files using vi, say? > No, it is a bit more in depth. FileTree, by default, will save some metadata with the packages (method timestamps, package version history) and this, with git, creates conflicts when merging (and cherry picking and a few other operations). GitFileTree introduced a variant of the format, called metadata-less, to avoid that and recover the metadata from the git history itself (and convert it to Monticello). > > Right now, after committing in Monticello Browser, when I click 'refresh' > or > 'changes' everything shows up as new again. That can't be right. Which > part of > GitFileTree deals that? > The all new again is the default FileTree approach. In GitFileTree, it recovers all the versions with git log and rebuild them for the repository browser. It is done starting with MCFileTreeRepository>>#gitVersionsForPackage:, then MCFileTreeGitRepository>>#getVersionsForPackageDirectoryName:, tied with a specific class to register the data for all entries (GitFileTreePackageEntry -> other repositories uses only strings to track all the versions). In there you also see the bridge which converts from git log metatadata to Monticello metadata (MCVersion and ancestry). Side question then: is Iceberg factoring out some of that out of GitFileTree, since it supports/supported the libgit and GitFileTree backends? Factoring out could also be of benefit to Fossil. Regards, Thierry > > Pierce > > >

March 1, 2017

Problems with PipeableOSProcess

by Silas Berger

Hi everyone, I'm currently experiencing problems with PipeableOSProcess. I'm using a command to run a third party tool, which reads a txt file and returns an XML string. In my collection, this works fine for about 75 out of 100 txt files, but fails on the remaining 25 ones. However, the tool itself doesn't fail. It works fine, if I issue the commands directly from a Terminal. Here's an example of a command string that works: /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/tools/mac/ parsecit/bin/citeExtract.pl -m extract_all /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/examplePDF sFromList/Ache00aScriptingCoordStyles.pdf.txt And here's an example of one that doesn't work. /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/tools/mac/ parsecit/bin/citeExtract.pl -m extract_all /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/examplePDF sFromList/Ardi97aSchemeTeaching.pdf.txt This is how I apply these commands through PipeableOSProcess: xml := (PipeableOSProcess command: cmdString) output. For the first command, xml is a large XML string, for the second command, it's just an empty string. As I've mentioned above, both commands work just fine in a Terminal. They both produce a correct XML string. Does anyone have an idea why this could be the case? Is there a way to access errors in the PipeableOSProcess, if there are any? Is there a better way to issue terminal commands from Pharo? Thanks for your help! Cheers, Silas

March 1, 2017