March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Request write access to PharoInbox

by Frank Shearar

On 28 March 2013 20:41, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hello, > can someone give me write access to PharoInbox? Me too, please. frank > Nicolas Cellier

March 29, 2013

Re: [Pharo-project] Platform and portable versions for Pharo 2.0 too

by Sean P. DeNigris

Marcus Denker-4 wrote > Please let it like it is and we move *controlled* forward. Okay I removed the links to the platform files from the download page for now. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Platform-and-portable-versions-for-Pharo-2-0-too-tp46… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 29, 2013

Re: [Pharo-project] [Moose-dev] Project Show & Tell - LEKtrek

by Alexandre Bergel

Looks like to be an excellent piece of work. Do you have a website or something? We would like to advertise this. Cheers, Alexandre On Mar 28, 2013, at 10:24 AM, Ben Coman <btc(a)openInWorld.com> wrote: > LEKtrek is "a software development platform for electrical power applications". This is my masters project to provide the GUI for modeling electrical power networks, into which researchers can plug calculations. > These video presentations are still a work in progress, but just in case you needed some filler for the Show Us Your Project sessions at PharoConf/MooseDay, please feel free to use any portion of the three videos listed below. These can be viewed using VLC. Note that the 020 video was the first I ever produced and suffers a little for quality until I can fix it after writing up my dissertation. Quality gets better in the later videos 010 and 030. > http://files.openinworld.com/LEKtrek/ > * LEKtrek 010 Introduction 2013-02-25.mp4 - 6min - background context for the project > * LEKtrek 020 Explorer User 2013-02-28.mp4 - 8min30 - a tool to explore the IEC 61970 Common Information Model (of electrical power networks) > * LEKtrek 030 Modeller User 2013-03-19.mp4 - 9min - a tool for modeling an electrical power network, and executing calculations on that model. > > The project is based on top of Roassal, Glamour & Magritte 3. It will released open-source, but I am still musing over the finer points of several licenses, which waits on completion of my dissertation. > > Any and all feedback on contents and aesthetics are welcome. > > cheers -ben > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 28, 2013

[Pharo-project] TxText progress and discussion

by Denis Kudriashov

Hello. I implement positioning text for new TxTextMorph. You can now see blinking cursor, move it right, left, up and down, position it by mouse click. I make new version 0.4 which restore jenkins builds https://ci.inria.fr/rmod/job/TxText/, You can try TxTextMorph class side example methods. Details: Cursor position at "visual text" presented by TxTextLayoutPosition. TxTextLayoutPosition has state: - textLayout - span - TxLayoutSpan (introduced by Igor suggestion) - spanPosition - index inside TxLayoutSpan - desiredOffset - desired x offset from start of "visual line". It can differ from actual (x,y) position - xyValue - actual (x,y) position inside "visual text" box. TxTextLayoutPosition implements moveRight. moveLeft, moveUp and moveDown methods. Desired offset allow moving up and down with remember of first offset. Example: 123456 123 123456 Cursor moves from up to bottom. Position of cursor at each line will be after red char. It is common behaviour of text editors. But our current text morph not works such way. And current text morph implements move up and move down in terms of index from start line. So it is visually incorrect up or down movement for no mono fonts. Try this to check it: WWWWWW - 6 W-characters, move from 6-th W-char down and try same at pharo. 1234567890 TxLayoutSpan present part of text span which placed at some line and has offset, extent and font. It was created by layout builder to fit text layout restrictions. When text span wrapped by max line width restriction It "splitted" for two or more LayoutSpan's. TxLayoutSpan has span interval (TxInterval). Igor was suggest removing explicit font attribute from text model and replace it with small font parts like family name, bold, underlined and others. He said it's should be responsibillity of "view system" to select appropriate font by this attributes. I don't know is it good idea. But I have some user cases where it is needed. So TxLayoutSpan allows such design decision. That's why it has font instance. TxLayoutSpan is created by layout builder which can select appropriate font for underlying spans. Now it just extracts font from span attributes like before. There is TxCursorMorph which presents blinking cursor (basic morph stepping logic). So visual text cursor is just submorph of TextMorph. I not yet implement any communication level between TxTextLayout, TxTextLayoutPosition and morphs. It is for future. Now morphs implemented to show what already works. I needs help with namings. All ideas are welcome. For example we have too much different position names: - TxPosition with vars linePosition, spanPosition - indexes - TxTextLayoutPosition with vars spanPosition (index of char), desiredOffset (x coordinate of offset inside line), xyValue (x@ycoordinates inside text box) - TxCharactersSpan methods: #isLastPosition: , #lastInsertPosition - indexes - TxLayoutSpan methods: #charPositionAtOffset: (char index at offset). #computeXYPositionAt:, #containsXPosition:, #endPosition (TxPosition). I want easily understand what kind of position method means. In TxLayoutSpan I try to distinct it by "charPosition" and "xyPosition". I dont sure it is nice. And I don't like name of TxLayoutSpan. (too many spans). Small tasks which I have in mind: - more cursor movement actions - make settings for shortcuts at TxTextMorph - make cursor actions dynamically connected to shortcut settings. Each cursor action (method) should automatically creates shortcut setting for it. There is strange problem with TxTextMorph when it is transparent. Try change #drawOn: method to see it (remove rectangle filling). Next I will implement events logic to update TxLayoutPosition when layout changed. And text selection stuff. Best regards, Denis

March 28, 2013

Re: [Pharo-project] Versionner in pharo 2.0

by Christophe Demarey

Le 28 mars 2013 Ã 14:13, Esteban Lorenzano a Ã©crit : > btw... why is there a ConfigurationOfVersionner in verified repo for 2.0 if it is not working (and therefore, it is not "verified")? What do you mean by "verified repo for 2.0" ?

March 28, 2013

[Pharo-project] Request write access to PharoInbox

by Nicolas Cellier

Hello, can someone give me write access to PharoInbox? Nicolas Cellier

March 28, 2013

Re: [Pharo-project] More GSoC ideas wanted, 3 days left ....

by Vanessa PeÃ±a Araya

Hi, I hope it is not too late :) We have some ideas we will like to do: * -=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=- Title: Improving Roassal Scalability Level: Intermediate Possible mentor: Vanessa PeÃ±a-Araya Possible second mentor:Alexandre Bergel Description: The Roassal visualization engine is getting more users in the Smalltalk community every day. This means more complex visualizations are created using Roassal, and the amount of data the user wants to represent is larger. However Roassal is still behind to answer this demands as it lacks from scalability for big visualizations, resulting in very slow displaying and events answering. In this project we plan to fix this problem and allow Roassal to become a efficient tool Technical Details: In this project the student will define and implement a strategy for faster displaying for the visualizations and events reaction. This includes understanding the techniques currently used in other visualization tools. Benefits to the Student: - Learn and understand Roassal, including its structure and design - Learn graphical tools techniques mainly for rendering and event responding Benefits to the Community: Allowing the community to have a faster and efficient visualization tool, making Roassal a powerful visualization engine and answering to the demand to render large amount of data. -=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=- Title:Composing layouts on Roassal Level:Begginer Possible mentor:Vanessa PeÃ±a-Araya Possible second mentor:Alexandre Bergel Description: Roassal includes a set of layouts to automatically arrange visual elements on a view, however this feature is very limited. When two different set of elements requires to be arranged in different way, a manual translation must be done to one of the set the particular layouts are applied, to avoid overlapping. There is also no way to compose layouts to create more complex distributions. For example, it is not possible to arrange a set of elements in a circle layout around a particular element, which itâs arranged in a grid with other elements. Technical Details: - Create a layout composer, allowing a view to organize its elements in different layouts easily and without arranging the elements âby handâ. Example: a view with the first 5 elements as a grid and the following 5 as a horizontal line, without manual translation. - Allow to compose layout not only for views but also for element, as the example described in the description. - Create an expressive command for use it in Roassal and its corresponding equivalent for the Mondrian DSL Benefits to the Student: - Learn and understand Roassal, including its structure and design - Understand Roassal and Mondrian expressive commands Benefits to the Community: The community will have a better way to create visualizations in Roassal. This will removing the need of unnecessary manual translation of elements, allowing to arrange visual elements in more complex distribution automatically. -=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=- Title: Improve the Roassal animation âengineâ Level:Beginner/Intermediate Possible mentor:Vanessa PeÃ±a-Araya Possible second mentor:Alexandre Bergel Description: Roassal allows to create animations with simple scripting. However to execute an animation after another, it is necessary to set a block containing the second animation to be executed once the first is finished. This means that for creating sequential animations a lot of work and scripting needs to be done. This project will provide a better way to create and display animations. Technical Details: The student will: - Create an animation composer, changing the need to define sequential animations by defining a block to be executed after an animation is finished. - Allow to set the amount of time an animation needs to be finished, instead of only allowing the number of cycles to do it. This allows for an animation to be completed in the same amount of time, in all the different platforms (Pharo, VW, VA, Amber) works. - Allow the possibility of stop an animation. If there is an animation sequence in which this one is included, start the following animation in the queue in a smooth manner. - Create an expressive command for use it in Roassal and its corresponding equivalent for the Mondrian DSL Benefits to the Student: - Learn and understand Roassal, including its structure and design - Learn about how animations are created in Roassal and other visualizations engines - Understand Roassal and Mondrian expressive commands Benefits to the Community: The community will have a better animations engine included in Roassal. -=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=- Cheers and thanks, Vanessa. * On 03/26/2013 07:36 AM, Janko MivÅ¡ek wrote: > Dear Pharoers, > > Ideas are slowly coming, 14 so far, but this is way below the 30+ in > previous years. So, stretch your brain, come with some more ideas, which > will be interesting for potential students and of course useful for our > community. Students you are again welcome to propose such idea by your > own. One student idea for now! > > Ideas so far: http://gsoc2013.esug.org/ideas > > To propose an idea just respond to this post by fulfilling this idea > template: > > Title: > > Level: (beginner, intermediate, advanced) > > Possible mentor: (if already known) > > Possible second mentor: (if already known) > > Description > > Technical Details > > Benefits to the Student > > Benefits to the Community > > Best regards > Serge and Janko, > your this year GSoC admins > >

March 28, 2013

Re: [Pharo-project] Suggestion about Phexample and StateSpecs(Mocketry) integration

by Denis Kudriashov

Ok. I can do this. I think showing examples from project wiki page is enough. Plus demo of how extend syntax sugar and how to use stubs. What people really want to see about mock objects framework? 2013/3/27 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > If you can write step by step instruction what to show, I can do it. Right > now all my time is used to prepare my own presentation, so I can't do it > myself. > > uko > > > > On 27 Ð±ÐµÑ. 2013, at 18:41, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2013/3/27 Tudor Girba <tudor(a)tudorgirba.com> > >> Perhaps Mocketry would be a good topic for a "Show us your projects" >> session. Then we can try to go into a couple of more details. >> >> > Unfortunately I can't participate conference this year > > >> Cheers, >> Doru >> >> >> On Mar 27, 2013, at 12:42 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> > Sounds good to me. >> > >> > On 26 Ð±ÐµÑ. 2013, at 23:00, Camillo Bruni <camillobruni(a)gmail.com> >> wrote: >> > >> >> >> >> On 2013-03-26, at 19:45, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >> >> >>> 2013/3/26 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> >>> >> >>>> Ok, and what if we will change behavior a bit so if no definitions >> were >> >>>> found it will send the incoming message to enclosed object? This way >> it >> >>>> will work like phexample but will also allow to define some fancy >> DSL. >> >>>> >> >>> >> >>> We can copy all phexample syntax methods into single class inside >> >>> StateSpecs package but replace implementation with pragmas approach. >> So >> >>> anybody can browse implementors like usual and it will not required >> any >> >>> special cases. >> >>> >> >>> How I can influence your interest, guys? I can provide cleaning, >> comments, >> >>> improvements to StateSpecs. I opened for your requirements. >> >>> Phexample become quite popular and can be part of Pharo sometimes. >> >>> Mocketry/StateSpecs used by people too. >> >>> It would be bad if this packages can't be used together. >> >> >> >> sorry for starting the whole rant :) I am veery busy at least until >> tomorrow >> >> >> >> Yuriy we can discuss that after tomorrow? >> >> I would as well appreciate some common solution to avoid the selector >> clash. >> >> >> >> >> >> >> >>>> On 26 Ð±ÐµÑ. 2013, at 07:46, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>>> >> >>>> Hello >> >>>> 2013/3/26 Camillo Bruni <camillobruni(a)gmail.com> >> >>>> >> >>>>> Definitely StateSpec looks more mature and can be used in a more >> flexible >> >>>>> way. >> >>>>> But I am not a big fan of the pragma magic. Why? >> >>>>> It breaks all tools for me :/. If I see a message send I want to be >> able >> >>>>> to: >> >>>>> - browse it, so I can see who implements it? >> >>>>> - debug it directly to get to the real method. >> >>>>> >> >>>>> SateSpec does indeed help writing readable code by allowing almost >> >>>>> grammatically >> >>>>> correct sentences. However I don't think this is the way to >> program. I am >> >>>>> a big >> >>>>> fan of stupid english: >> >>>>> >> >>>>> `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >> >>>>> >> >>>>> If I want to figure out how the first one works, I can simply >> browse the >> >>>>> implementors of #should and/or #isKindOf: where is the StateSpec >> version >> >>>>> I am >> >>>>> lost. I have to rely on "contains string literal" to get the >> sources, for >> >>>>> me >> >>>>> that is very strange. >> >>>>> >> >>>> >> >>>> I think main thing you want is easilly explore all available should >> >>>> syntax. And StateSpecs can be easilly adopted for such task. We can >> just >> >>>> move all methods with syntax pragmas to single class. So you can >> open this >> >>>> class and see what available. >> >>>> >> >>>> To get implementors of some "should expression" you should use >> senders >> >>>> search of syntax words instead of implementors. Syntax words in >> StateSpecs >> >>>> is just method literals ( <syntax: #(be an instance of:)>, #() is >> just >> >>>> array of symbols). >> >>>> >> >>>> Interesting that StateSpecs has more explicit syntax system. How you >> can >> >>>> explore in Phexample expression: >> >>>> >> >>>> object should be true >> >>>> ? >> >>>> >> >>>> You have separate PheMatcher>>be and PheMatcher>>true methods and >> there is >> >>>> no places in code where you can see that this messages can and >> should be >> >>>> used together. >> >>>> But with StateSpecs you should put pragma with explicit expression >> like: >> >>>> >> >>>> Equal>>true: anObject >> >>>> <syntax: #(be true)> >> >>>> ^self return: (IdentitySpec pattern: true) >> >>>> >> >>>> So with StateSpecs you have full syntax expression at one place >> which can >> >>>> be easy explored. >> >>>> And for example to support Phexample mesage #beTrue you should just >> add >> >>>> another pragma: >> >>>> >> >>>> Equal>>true: anObject >> >>>> <syntax: #(be true)> >> >>>> <syntax: #(beTrue)> >> >>>> ^self return: (IdentitySpec pattern: true) >> >>>> >> >>>> So with Phexample you can browse implementors of "single word should >> >>>> expressions". But with Phexample if you browse implementors of #be >> like >> >>>> messages you have no idea how it can be used. >> >>>> In StateSpecs you should use senders. And with StateSpecs if you >> browse >> >>>> "any syntax word implementors" by senders seach you will see all >> possible >> >>>> usage cases. And if I move all methods with syntax pragmas to single >> class >> >>>> you can easilly see all possible expressions in one place. >> >>>> >> >>>> `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >> >>>>> >> >>>> >> >>>> With StateSpecs it should be >> >>>> >> >>>> foo should be a kind of: Bar >> >>>> >> >>>> And as I said before It is simple task to support all Phexample >> >>>> expressions by StateSpecs pragmas >> >>>> >> >>>> Best regards, >> >>>> Denis >> >>>> >> >>>> >> >>>> >> >> >> >> >> > >> > >> >> -- >> www.tudorgirba.com >> >> "Sometimes the best solution is not the best solution." >> >> >> > >

March 28, 2013

[Pharo-project] [ANN] Fuel Release Version 1.9

by Martin Dias

Hi all, We are happy to announce Fuel 1.9. Fuel is an open-source general-purpose object serialization framework developed in Pharo. You can find more information on our website [1]. The default set of packages of this version already comes in Pharo 2.0, so you it's not necessary to install it there. However, Fuel also works out-of-the-box in Pharo from 1.1 up to 2.0, as well as in Squeak 4.1 up to 4.4. You can see our documentation [2] for complete installation and use guides. Changes: - (feature) DoIt and not-installed CompiledMethods are fully serialized by default. - (fix) Date & DateAndTime (thanks Cami and Marcus) (already included in Fuel 1.8.1 and 1.8.2). - (feature) New hooks methods #fuelNew and #fuelNew: for custom instantiation (see "Hooking instance creation" in Customizing the Graph). - Globals: - Added #globalEnvironment: to specify where the globals are looked-up. (see "Changing the environment" in Managing Globals). - Explicit references to "Smalltalk globals" changed to "self class environment". - A SystemDictionary instance is not treated as global when it is not "Smalltalk globals". - Documentation: - General update - New Format Migration section. - New Built-in Header Support section. - (feature) Put back FLSerializer>>on:. - (optimization) New clusters for SmallInteger. - (optimization) New clusters for most common collections. - (feature) Built-in support for header (See Built-in Header Support): - pre and post materialization actions (clean closures). - attach additional objects. - materialize only the header. - (fix) Safer substitutions (see FLPluggableSubstitutionTest>>testPrivateExcluded). - (feature) Materialize .fuel files when drag&dropped in the image. - (cleanup) Removed unneeded cluster: FLWellKnownObjectsCluster. [1]: http://rmod.lille.inria.fr/web/pier/software/Fuel [2]: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation<http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation> We want to thank developers of the community that enrich the project with code, issue reports and ideas. Have fun! Martin (on behalf of Mariano and Max, who worked a lot on this version)

March 28, 2013

Re: [Pharo-project] Non-Smalltalk content in Pharo and Nautilus

by S Krish

I would love to have one for Groovy..! On Thu, Mar 28, 2013 at 1:48 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > When working with Seaside (or other frameworks) one often works with > non-Smalltalk resources > stored within the image (CSS styles, images, ...) often stored as strings > within > methods: > > > myCss > ^'body { > background-color: #ffffce; > }' > > or > > script > ^'alert("hello from Javascript");' > > > I also often see Base64 encoded images, or when working with XML a method > might return XML content. > > With things like Helvetia [1], the reworked autocompletion/syntax > highlighting and new > browsers like Nautilus in mind I wonder if (may be in the not so far > future) I can: > > - click on a Smalltalk method to get ST styling and edit functionality > - click on a CSS content method to do CSS styling and completion > - click on a method with a form content to display the picture (and not > the Base64 encoded string) > - click on an XML content to browse the XML tree > - click on an HTML providing method to edit HTML and maybe preview > - click on a method with CSV to edit the tabular data within a grid > - click on a primitive method to see Slang or C/C++ code > - ... > > Internally the content can be distinguished using pragmas: > > > myCss > <mime-type: text/css> > ^'body { > background-color: #ffffce; > }' > > > Are there any plans to move Pharo into this "not only Smalltalk" in > methods direction? > > Is it already possible to easily extend Nautilus with "pluggable" custom > panes depending on the > method content. > > I see that there are buttons on the Nautilus side. Wouldnt it be better to > have "Tabs" > with "Source" as default and where I can add my own custom tabs? > > Would be a lot of work to provide editors and stylers for all the > mime-types or autocompletion > for JavaScript, SQL, ... whatever. But the question is more "do we have > the groundwork so > people can built up on it." > > Any comments? > > Thx > T. > > [1] http://scg.unibe.ch/research/helvetia > > >

March 28, 2013