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

Re: [Pharo-users] Seaside : including a static stylesheet.

by Dominique Dartois

Thank you Sven. I have tried successfully the FileLibrary but I want to be able to modify the stylesheet without using Pharo which will be running on a remote server. Using static documents seemed the solution to me. > On 28 Feb 2017, at 18:53, Dominique Dartois <dom(a)dartois.org> wrote: > > In the Seaside book, chapter 17.2 I read I can include a stylesheet this way : > > updateRoot: anHtmlRoot > super updateRoot: anHtmlRoot. > anHtmlRoot stylesheet url: 'http://seaside.st/styles/main.css' > > On my development machine (macOS) I use http://localhost:8080/myApp as the server address and I don?t know the root directory of the Seaside integrated web server. > > Can anyone help me to find this directory? The easiest way is to use a Seaside FileLibrary subclass to serve your static CSS file. This is described in that same chapter 17. > Thanks. --- Dominique Dartois

March 1, 2017

[ANN] Regex Tester Tool for Pharo

by Torsten Bergmann

Hi, I wrote a little tool to test regular expressions and verify that given samples match it. It also helps to divide an expression into subexpressions to retrieve parts of a matched string. Screenshot is attached. Code, load instructions and full tutorial on how to use it is on https://github.com/astares/Pharo-Regex-Tools Hope it is useful for others too. Have fun! Bye T.

March 1, 2017

Re: [Pharo-users] Voyage and Association

by Hilaire

It will, thanks Le 01/03/2017 Ã 20:42, Esteban Lorenzano a Ã©crit : > hope this helps, -- Dr. Geo http://drgeo.eu

March 1, 2017

Re: [Pharo-users] Voyage and Association

by Esteban Lorenzano

Hi Hilaire, the thing is mongo is JSON based and in JSON dictionaries are key-string, value-anything so we cannot persist them âas isâ. To do that I use a trick which is convert them to collections before persisting, using a helper class that comes with Voyage-Mongo, VOMongoKeyPair. For example, you could describe your dictionary attribute as this: mongoValue <voyageDescription> ^VOToManyDescription new attributeName: 'value'; convertNullTo: [ Dictionary new ]; accessor: (MAPluggableAccessor read: [ :anObject | anObject value associations collect: [ :each | VOMongoKeyPair fromAssociation: each ] ] write: [ :anObject :value | (value collect: #asAssociation) asDictionary ]); yourself hope this helps, cheers! Esteban > On 1 Mar 2017, at 19:11, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi, > > I am having trouble to persist in a Voyage repository Association formed > with a key being a non string object (let's say a Month) and value a non > basic object, instance of a model object. > > So far, I have an error bsonTypeCode not understood on my value object. > I could implement bsonTypeCode, but I suspect I will have trouble too > with the key, as I see from Voyage code it is persisted as a String. > > An idea how to overcome this (without modifying my model)? > > Fuel was persisting it fine. > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > >

March 1, 2017

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

by phil＠highoctane.be

One usually puts things like: self flag: #TODO. "Need to fix this hack" self flag: #FIXME. "Quick kludgy temp solution" Some write: self flag: 'Must add such or such feature'. Then start Spotter and search for flag: senders with flag: #se There is already quite a list in the image. Phil On Wed, Mar 1, 2017 at 7:04 PM, Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch> wrote: > Hi Hilaire, > > great! > > Is there a standard or conventional set of pragmas for such kind of > annotations? I mean, pragmas are very flexible but I would like to adhere > to well-established conventions, if possible. > > > > On 2017-03-01 18:59, Hilaire wrote: > >> 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 >>> >>> >> > > >

March 1, 2017

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

by Serge Stinckwich

*** Please forward this message to students that might be interested *** 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/ Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback (think IDE and OS rolled into one). Everything in Pharo is an object. The entire syntax of Pharo fits on a postcard coding can be done directly in the debugger. Pharo has super cool tools that empower you and make you super efficient. Pharo's goal is to deliver a clean, innovative, free and open-source immersive environment. By providing a stable and small core system, excellent developing tools, and maintained releases, Pharo is an attractive platform to build and deploy mission critical applications. Pharo fosters a healthy ecosystem of both private and commercial contributors who advance and maintain the core system and its external packages. More information about Pharo is available here: http://www.pharo.org/ We invite all the prospective eligible students to code their summer away with Pharo Consortium. Student Responsibilities ...to your Mentor - Submit quality work - Regularly communicate work completed, what you intend to do next, and blockers - Ask for help when something is preventing you from achieving a goal - Give indication that you are alive and working daily (GSoC) - Re-evaluate work scope when significantly ahead of expectations (GSoC) - Communicate with your mentor AND the broader community - Inform when work capacity will be reduced, as early as possible (e.g., family, health, other work) (GSoC) - Listen and respond to feedback ...to the Org Admin Let them know when there are - Interaction issues with any mentor or community member - Significant disagreements involving your work or changes to your work plan Read more about responsibilities here: https://developers.google.com/open-source/gsoc/help/responsibilities Hence, we invite enthusiastic student developers contributors to work with Pharo Consortium for GSoC 2017. 1. A first list of projects are available here : http://gsoc.pharo.org/ but more can be found by interacting with mentors from the Pharo community. 2. Join dedicated channels, #gsoc-students for general interactions with students on Pharo slack. In order to get an invitation for pharoproject.slack.com visit the URL here: http://slackinvites.pharo.org/ Discuss with mentors about the complexity and skills required for the different projects. 3. Please help fix bugs, open relevant issues, suggest changes, additional features, help build a roadmap, and interact with mentors on mailing list and/or slack to get a better insight into projects. Better the contributions, Better are the chances of selection. Before applying: * Knowledge about OOP * Basic idea about Pharo & Smalltalk syntax and ongoing projects * Past experience with Pharo & Smalltalk * Interaction with organisation You can start with the Pharo MOOC : http://files.pharo.org/mooc/ Guidelines for Proposal: * Introduction: Clearly defined problem. Current state of things. Issues you wish to solve and why. Conclude with solution. * Project goals: Format it like a list. Propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. âFuture developmentsâ can be mentioned. It is better to promise less and deliver more than to promise a lot and then fall short. * Implementation: Longer and more detailed. Provide technical details, show that you understand the technology and illustrate key technical elements of your proposed solution. * Timeline: Make it weekly. Set goals for each week. Be upfront about other commitments, including exams, classes, travel, internships, jobs, etc. * Benefits to Community: Make your case a benefit to the organization. * Related Work: Research and write how the project fits into the target organization. Explain related works, similarities & differences. * About me: Provide full contact information, email addresses, websites, IRC nick, postal address and telephone. Write a few sentences about yourself, previous experiences and why you think youâre the best for this job. Submit your proposal early. Keep it short. Include necessary information. Get it reviewed in the mailing list or Slack channel before submitting it. The deadline for submitting your proposal is March 20th to April 3rd on https://summerofcode.withgoogle.com/ Looking forward to great talent joining our organisation this summer. Warm Regards Pharo Organisation Admins (Alexandre Bergel, Jigyasa Grover, Serge Stinckwich & Yuriy Tymchuk)

March 1, 2017

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

by Norbert Hartl

Yes, #flag: is the way to go. I often use something like self flag: #needsWork If you use symbols then you can just mark the needsWork and search for senders (cmd-n on Mac). That gives you all of the locations in the image where it is used. Norbert > Am 01.03.2017 um 19:06 schrieb Peter Uhnak <i.uhnak(a)gmail.com>: > > On Wed, Mar 01, 2017 at 06:53:16PM +0100, Raffaello Giulietti wrote: >> 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 >> > > The most common is `self flag: 'text'`. This will give you an icon in Nautilus browser. > > But keep in mind that IDEs impose special syntax because they do not provide you with option to retrieve it yourself. > In Pharo there is no such restriction, so you can do whatever you find most practical to you and then just collect the places yourself. > > E.g. you can trivally retrieve all methods that have "todo" anywhere in method comment: > > ('My-Package' asPackage classes flatCollect: #methods) > select: [ :each | each comment isNotNil and: [ each comment includesSubstring: 'todo' ] ] > > Peter >

March 1, 2017

Voyage and Association

by Hilaire

Hi, I am having trouble to persist in a Voyage repository Association formed with a key being a non string object (let's say a Month) and value a non basic object, instance of a model object. So far, I have an error bsonTypeCode not understood on my value object. I could implement bsonTypeCode, but I suspect I will have trouble too with the key, as I see from Voyage code it is persisted as a String. An idea how to overcome this (without modifying my model)? Fuel was persisting it fine. Thanks Hilaire -- Dr. Geo http://drgeo.eu

March 1, 2017

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

by Peter Uhnak

On Wed, Mar 01, 2017 at 06:53:16PM +0100, Raffaello Giulietti wrote: > 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 > The most common is `self flag: 'text'`. This will give you an icon in Nautilus browser. But keep in mind that IDEs impose special syntax because they do not provide you with option to retrieve it yourself. In Pharo there is no such restriction, so you can do whatever you find most practical to you and then just collect the places yourself. E.g. you can trivally retrieve all methods that have "todo" anywhere in method comment: ('My-Package' asPackage classes flatCollect: #methods) select: [ :each | each comment isNotNil and: [ each comment includesSubstring: 'todo' ] ] Peter

March 1, 2017

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

by Raffaello Giulietti

Hi Hilaire, great! Is there a standard or conventional set of pragmas for such kind of annotations? I mean, pragmas are very flexible but I would like to adhere to well-established conventions, if possible. On 2017-03-01 18:59, Hilaire wrote: > 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 >> >

March 1, 2017