- Pharo-users - lists.pharo.org

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

Google Summer of Code 2017: Call for mentors for Pharo Consortium

by Serge Stinckwich

Heartiest Congratulations ! Pharo Consortium has been selected as a mentor organisation for Google Summer of Code 2017. Google Summer of Code is a global program focused on introducing students to open source software development. Students work on a 3 month programming project with an open source organisation during their break from university. Read more at https://summerofcode.withgoogle.com/ How the program works ? Organizations: Open source projects apply to be mentor organizations. Once accepted, organizations discuss possible ideas with students and then decide on the proposals they wish to mentor for the summer. They provide mentors to help guide each student through the program. Mentors: Existing contributors with the organizations can choose to mentor a student project. Mentors and students work together to determine appropriate milestones and requirements for the summer. Mentor interaction is a vital part of the program. A mentor may propose or endorse a project and each project has to be about Pharo or its ecosystem (e.g., a library). Projects will be mentored by one or more mentors and executed by one student. Students: Students contact the mentor organizations they want to work with and write up a project proposal for the summer. If accepted, students spend a month integrating with their organizations prior to the start of coding. Students then have three months to code, meeting the deadlines agreed upon with their mentors. Student coding period: May 30 - Aug 29 (Entire timeline can be viewed at: https://summerofcode.withgoogle.com/how-it-works/#timeline) Student stipend: https://developers.google.com/open-source/gsoc/help/student-stipends We are currently at the phase of identifying mentors and projects. The next phases will be about students selecting projects, and the community selecting the projects with their associated mentors and students which will be sponsored by the GSOC program. How to register ? Simply by replying to this email and joining the Slack channel... to have more discussion about what project the mentor will take up, what she/he wants at the end of the coding period and then we can invite them to the GSoC org dashboard). Hence, we invite regular & enthusiastic Pharo contributors to be a mentor with Pharo Consortium for GSoC 2017: 1. Kindly respond on this thread if you'd like to be a mentor, or wish to propose a project. An existing list of projects is already available here: http://gsoc.pharo.org/ and we already have a handful of projects and mentors chosen. Feel free to collaborate with existing mentors as well. 2. Join dedicated channels, #gsoc-students for general interactions with students & #gsoc-planning channel only for GSOC admins and mentors on Pharo slack. In order to get an invitation for pharoproject.slack.com visit the URL here: http://slackinvites.pharo.org/ 3. Please open relevant issues and make a roadmap of the projects being mentored by you so that students can start contributing to them already. If you want to mentor a project and there is no open-source repository at the moment, please built one ASAP. 4. If you know any students that might be interested to work on Pharo during the summer and be a part of GSoC as well, please ask him/her to start contributing to the Pharo projects, discuss their proposal, follow instructions that shall be posted soon in this mailing thread and submit their application by April 3, 2017. We don't know the number of slots attributed by Google to Pharo org, but the more students proposal we will receive, the more slots will be attributed to us. We remind you about the mentor responsibilities: ... to your Org Admins - Communicate availability and interaction expectations - Inform when mentoring capacity will be reduced, as early as possible (e.g., family, health, vacation) - Inform when there is an issue with a student - Lacking communication, activity, visibility (MIA), or progress - Participant Agreement violations (e.g., plagiarism, harassment, fraud) - Bad fit or stepping down - Formally evaluate student participation. - Communicate with admin and student before failing ... to your Students - Help and/or teach the student - how to be a part of your community - communicate more effectively and in the open - work with your orgâs preferred communication channel (IRC, Slack, etc) - use your orgâs version control system - ask good questions and get answers to their questions - provide convincing technical argument and constructive discussion - be independently motivated and productive - solve difficult technical problems - Keep track of their progress, keep student informed as to their status - Communicate on a regular basis, once a week or better (for GSoC) - Give constructive feedback, be patient, and be respectful - Respond to questions within 24 hours (occasionally under 36 hours is ok) - Establish realistic work objectives and timeline expectations - Re-evaluate scope with student when significantly ahead of or behind expectations - Work with devs and community to facilitate acceptance of student work Read more about responsibilities here: https://developers.google.com/open-source/gsoc/help/responsibilities Looking forward to a great guided summer by the talented mentors of our organisation. Warm Regards Pharo Organisation Admins (Alexandre Bergel, Jigyasa Grover, Serge Stinckwich & Yuriy Tymchuk)

March 1, 2017