Re: [Pharo-dev] [ANN] Grouper
Hello Esteban, Le 9/12/19 à 19:22, Esteban Maringolo a écrit : Hi Julien, Interesting, in the last years I've been using a similar set of classes that build groups, and can also nest them, but yours seems more customizable. Cool! Is your code available somewhere? Maybe our ideas are different so Grouper could profit from that? Thank you for sharing it. I'll give it a try! Cool. :-) Julien
[Pharo-dev] [ANN] Grouper
Hello, I made a small library that reify grouping (that one does via #groupBy: usually): Grouper https://github.com/juliendelplanque/Grouper It is designed in the same spirit as SortFunction, but for grouping. Quick example: The following code snippet using Grouper: (10 to: 50)groupUsing: [:integer | integer asString first ]. "an OrderedDictionary( $1->#(10 11 12 13 14 15 16 17 18 19) $2->#(20 21 22 23 24 25 26 27 28 29) $3->#(30 31 32 33 34 35 36 37 38 39) $4->#(40 41 42 43 44 45 46 47 48 49) $5->#(50))" is equivalent to the following code snippet using built-in|#groupedBy:|method: (10 to: 50)groupedBy: [:integer | integer asString first ] "an OrderedDictionary( $1->#(10 11 12 13 14 15 16 17 18 19) $2->#(20 21 22 23 24 25 26 27 28 29) $3->#(30 31 32 33 34 35 36 37 38 39) $4->#(40 41 42 43 44 45 46 47 48 49) $5->#(50))" The advantage of using it is that it allows one to compose grouper objects. Thus, it is easy to describe grouping on 2 or 3 levels. Fore example: The power of Grouper is that group description are first-class objects. Thus, it is possible to compose group descriptions in order to group a flat collection on multiple levels. For example: groupComposition:= [:integer | integer asString first ] grouper , [:integer | integer asString second ]. (10 to: 50)groupUsing: groupComposition. "an OrderedDictionary( $1->an OrderedDictionary( $0->#(10) $1->#(11) $2->#(12) $3->#(13) $4->#(14) $5->#(15) $6->#(16) $7->#(17) $8->#(18) $9->#(19)) $2->an OrderedDictionary( $0->#(20) $1->#(21) $2->#(22) $3->#(23) $4->#(24) $5->#(25) $6->#(26) $7->#(27) $8->#(28) $9->#(29)) $3->an OrderedDictionary( $0->#(30) $1->#(31) $2->#(32) $3->#(33) $4->#(34) $5->#(35) $6->#(36) $7->#(37) $8->#(38) $9->#(39)) $4->an OrderedDictionary( $0->#(40) $1->#(41) $2->#(42) $3->#(43) $4->#(44) $5->#(45) $6->#(46) $7->#(47) $8->#(48) $9->#(49)) $5->an OrderedDictionary($0->#(50)))" On the github, there are more example showing how to build trees with custom objects. Any feedback for this library is welcome. I would like to propose it to Pharo in the near future because it would simplify a lot of code in DrTests (related to result tree views, the tree on the right of the UI). I don't know if it will be possible before next release as we are in feature freeze. Cheers, Julien
Re: [Pharo-dev] MDLApplication
Hello Sven, Did you try https://github.com/jecisc/MDBaseGenerator ? It generates a nice template for starting a new MDL webapp. I do not know about MDLApplication. Cheers, Julien Le 28/11/19 à 11:16, Sven Van Caekenberghe a écrit : Hi, I am trying to use MaterialDesignLite (master branch in Pharo 7). The demo works perfectly. Now, I thought I would start writing a small web app by subclassing MDLApplication, since that seems to set up things properly. Is that class finished ? How am I supposed to use it ? There are screens, but how are these rendered ? Do I have to do this myself ? Must there not be an idea of a current screen ? MDLScreen is in fact an empty class. Although there are units tests for MDLApplication, there is no subclass, so no actual user. It feels a bit as if the demo should/could use it. Sven
Re: [Pharo-dev] DrTest - strange UI effect and some feedback
Hello Torsten, First of all, thanks for your feedback. Le 22/11/19 à 09:15, Torsten Bergmann a écrit : Hi, DrTest is integrated into Pharo 8 now - but there seems to be a strange bug in overlapping widgets when one uses the grouping selection box. See attached screenshot. I opened an issue for that: https://github.com/pharo-project/pharo/issues/5205 for Pharo. Dont know if that is known bug or even already fixed in the original repo of DrTest. Would be good if the authors (Julien or Dayne) could check. I am not sure what causes this bug, I will need to check with Spec2 developers because I think as Spec2 users we do not have control on such behaviour of the droplist. Additional feedback: It's really a nice tool - but I see myself still switching back to old TestRunner again. Two reasons: 1. Compared to the regular TestRunner where one is able to see the failing tests directly in DrTest one always has to have additional clicks in the grouping tree on the left before getting the final results. So the default grouping of the results as a tree could be disturbing because it requires more clicking around. Would be a nice addition if there would be an additional "no grouping" mode as well so the results are just shown in a list like in reglar TestRunner. I agree with you, an additional iteration needs to be done on the grouping feature. We will take your feedback into account. 2. The old TestRunner had (after filtering the package) an additional useful context menu with "Select all" and "Select none", "Select inversion", which allowed easier focusing on the test classes I want to check. Would be nice if a similar one could be added. For "Select all" it is possible to do it via Cmd+A or Ctrl+A, as it is the standard for list selection in UI frameworks. For the "Select none" I am not sure that we want to support that action because it feels a bit odd. Why would one want to have nothing selected? But if one can justify why this is needed, we can add it of course. "Select inversion" could be added but again I think this is a bit odd feature. Now you have to know that DrTests is a side project for me and for right now I can not allocate that much time on it. So I will do my best to fix urgent issues ASAP. I already have a great list of issues since the integration (which is normal). :-) However, until next friday, I am in a rush for another deadline. Julien
Re: [Pharo-dev] Pharo Branding Organization on GitHub
Nice initiative Torsten! Cheers, Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 4 sept. 2019 à 17:25, Torsten Bergmann a écrit : > > Hi, > > the Pharo community is growing and our lovely Pharo system is an innovation > driver with cool tools and projects > but it is also used in real projects in research and business setups. > > There are still many entries left on all our TODO lists - not only in shaping > the next stable Pharo release(s) > but also in bringing more attention to people about what Pharo is all about. > > A few of us already follow a well know marketing phrase: “Do good and talk > about it!” as some report about Pharo news > in BLOGS, on TWITTER or by writing articles on MEDIUM.com or even books. I > also like that we have a growing number > of YOUTUBE videos about Pharo. We also have a regular Newsletter - even a > Facebook page, ... > > This gives visibility to Pharo activities and is already a good step in doing > some advertising. > > An additional important lesson in successful marketing is that one has to > give a homogenous "Brand Identity" to a project or product > to be easily recognizable and rememberable over time. We already have the > nice lighthouse and use it all over - but often it > is hard to find the logo or other marketing material in correct size or > correct graphics format. We should improve on that side > too. > > As we work mostly with git I therefore now have setup a new organization > "pharo-brand": > > https://github.com/pharo-brand > > that should give easy access and group existing branding material in one > place. > > The site now already includes the following three projects: > > 1. pharo-brand-material > > This should be the place for "logo" and "logo-flat". In the > subdirectories you will find the logo in three different > variations: > > - logo composed of text + icon + beacon > - logo composed of icon + beacon > - logo beacon only > > including subdirectories for "vector" (like SVG, PDF) and "screen" > formats (like PNG, BMP, ...) > > 2. pharo-github-images > > These are the Icons i created for the various github organizations like > > - https://github.com/pharo-project > - https://github.com/pharo-nosql > - https://github.com/pharo-rdbms > - https://github.com/pharo-contributions > - https://github.com/pharo-brand > > and a template for additional ones > > 3. pharo-jingle > > A jingle is a short song or tune used in advertising. Jingles are a form > of sound and or video branding - when you see it often > as an intro or outro you will more easily remember the brand name (Pharo > in this case). > > This repository includes a "Pharo jingle" that can be used as a start or > end section within own custom videos about Pharo and > related projects. > > The short video jingle was created using a free video software called > OpenShot using a sound jingle from freesound.org > > - Pharo_HDV720_24p_1280x720.mp4 > - Pharo_HDV1080_25p_1920x1080.mp4 > - Pharo_HDV1440_25p_1440x1080.mp4 > > Note that the jingle is currently a proposal - if you have better ones we > can discuss it within the community on the mailinglist. > > > I hope the repos will improve a little bit the situation in finding and > organizing the brand material. > Feel free to comment and give feedback or even add marketing material > (templates, icons or other) yourself to the repos. > > Thanks > T. >
[Pharo-dev] SequenceableCollection>>#allButFirst: inconsistence across subclasses
Hello, I opened that issue: https://github.com/pharo-project/pharo/issues/4442 <https://github.com/pharo-project/pharo/issues/4442> And I think to fix it we need to actually discuss about what we want. #allButFirst: behaves differently depending on the actual type of sequenceable collection when argument is greater than collection size. For instance: #(1 2) allButFirst: 3. "PrimitiveFailed signaled" (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled" (OrderedCollection with: 1 with: 2) allButFirst: 3. "an OrderedCollection() » The question is then, who is right? Should #allButFirst: with an argument greater than the collection size raise an error Or Should #allButFirst: with an argument greater than the collection size returns an empty collection ? I asked a few people about it @ ESUG and it appears that the expected behaviour from #allButFirst: is not the same to all people. We need to decide so we improve consistence of collections. And then, we need to document that with a test :-). Cheers. Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40
Re: [Pharo-dev] [Pharo-users] [ANN] OSWinSubprocess a library to spawn Windows System processes
Done. https://github.com/pharo-open-documentation/awesome-pharo/pull/89 <https://github.com/pharo-open-documentation/awesome-pharo/pull/89> Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 9 juil. 2019 à 08:43, ducasse a écrit : > > It would be good to add this in the awesome documentation. > > Stef > >> On 8 Jul 2019, at 20:44, Torsten Bergmann wrote: >> >> Without having a deeper look I guess what was done for Windows now is >> wrapping the usual STARTUPINFO, CreateProcess() >> functions and friends yet again ... >> >> >> Such wrappers and many other native friends were created from my side >> already years ago with my "OS-XXX" series >> of projects for different platforms: >> >> - http://smalltalkhub.com/#!/~OS/OS-Windows >> - http://smalltalkhub.com/#!/~OS/OS-OSX >> - http://smalltalkhub.com/#!/~OS/OS-Unix >> - http://smalltalkhub.com/#!/~OS/OS-Linux-CentOS >> - http://smalltalkhub.com/#!/~OS/OS-Linux-Ubuntu >> - http://smalltalkhub.com/#!/~OS/OS-Raspbian >> >> So for instance on Windows you could easily use >> >> WinProcess createProcess: 'explorer.exe' >> >> or >> >> WinProcess createAndWaitForProcess: 'cmd.exe'. >> >> The projects are available on Github now since 2018 and kept up to date for >> recent Pharo versions. >> >> - https://github.com/astares/Pharo-OS-Windows >> - https://github.com/astares/Pharo-OS-OSX >> - https://github.com/astares/Pharo-OS-Unix >> - https://github.com/astares/Pharo-OS-Linux-Ubuntu >> - https://github.com/astares/Pharo-OS-Raspbian >> >> All of them are available in Catalog. >> >> I have no problem with more and more implementations and the double efforts. >> But for Pharo users I have the feeling >> that it gets more and more confusing in the area of OSProcess, OSSubProcess, >> OSWinSubprocess, and more wrappers >> for basically the same thing ... >> >> Bye >> Torsten (aka astares) >> >> > > >
Re: [Pharo-dev] JSON RPC
Hello, > Le 14 juin 2019 à 00:16, Gabriel Cotelli a écrit : > > I will implement some basic RPC-like services so it looks like a good option. > > I noticed the Server and Client are in the same package. May I propose a PR > including some groups in the baseline to load only the server or client > functionality? Sure, propose a PR and I will create a new release with it. > Seems to be also some bugs fixed in the master branch but so fat not included > in any release. I create a new release right now with the fix. > > Anyhow, if you're happy receiving changes, I can propose some package > splitting and changes to the travis configuration to also calculate the > coverage of the code. Sure, please do! :-) Cheers, Julien
Re: [Pharo-dev] JSON RPC
Hello, I know it used by JRPCDebugger [1]. I also used it to interact with numpy by exposing math functions via a python JRPC server but I have no public repository for it yet. I did a comparison of this implementation with others available in Pharo world at the bottom of the README. Tell me if you have specific questions. Cheers, Julien Links: [1]: https://github.com/aranega/JRPCDebugger --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 13 juin 2019 à 20:45, Gabriel Cotelli a écrit : > > Hi! > > Is anyone using https://github.com/juliendelplanque/JRPC/ > <https://github.com/juliendelplanque/JRPC/> or other JSON RPC implementation > in Pharo? > > Regards, > Gabriel
Re: [Pharo-dev] Variables in auto-completion
--- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 28 mars 2019 à 11:15, Cyril Ferlicot a écrit : > > Hi, > > I remember that in old Pharo versions, the auto-completion added the > variables at the top of the completion list. Now they are at the > bottom under the classes. > > The original version worked better for me. I preferred previous version as well. Cheers, Julien > The current version really > annoys me since most of the time I would prefer to have a variables > completed. Is there a setting somewhere to get the old behavior back? > If not, does someone knowing the implementation of the auto-completion > knows where I could put a metalink to get the old behavior back for > me? > > -- > Cyril Ferlicot > https://ferlicot.fr >
Re: [Pharo-dev] [ANN] Pharo open documentation
Looks like an error. Will fix it. Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 30 janv. 2019 à 21:25, Hernán Morales Durand a > écrit : > > Hi Cyril, > > Nice project! > I think you forgot to add the URL : > https://github.com/pharo-open-documentation/awesome-pharo > <https://github.com/pharo-open-documentation/awesome-pharo> > > Note: the Zinc entry has a reference to Cytoscape.js? > > Cheers, > > Hernán > > > > El mié., 30 ene. 2019 a las 11:01, Cyril Ferlicot ( <mailto:cyril.ferli...@gmail.com>>) escribió: > Hi everyone! > > With some other members of the community we are proud to announce a > new effort on Pharo documentation. > > We launched an organization pharo-open-documentation which is a > user-maintained documentation related to Pharo environment, language, > and libraries. > > Currently it has three main projects: > - pharo-wiki : Wiki related to the Pharo programming language and environment. > - awesome-pharo : A collection of awesome Pharo libraries, tools, > frameworks and software. We want to make this project a reference in > https://github.com/sindresorhus/awesome > <https://github.com/sindresorhus/awesome> > - awesome-pharo-ml : List of projects, books, booklets, papers, and > applications related to machine learning, AI, data science in Pharo. > > Contributions are welcomed! > > If you own a cool project in Pharo others could use in their own > projects, send us a PR to awesome-pharo! > If you have knowledge on Pharo or projects of Pharo, we would be glad > if you could contribute to the pharo-wiki! Don't forget to read the > contribution guidelines. ;) > > We opened a Twitter to announce new entries on the pharo-wiki. > > https://twitter.com/PharoOpen <https://twitter.com/PharoOpen> > > Have a nice day! > > -- > Cyril Ferlicot > https://ferlicot.fr <https://ferlicot.fr/> >
Re: [Pharo-dev] [Moose-dev] Re: Migrate PetitParser (1) on GitHub under moosetechnology organisation?
Sure, I will keep the history. I will see how much time it takes to migrate PetitParser. If it does not take too much time, maybe I will do it for the two others repository. Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 3 déc. 2018 à 15:55, Andrei Chis a écrit : > > Hi, > > That's definitely a good idea. > > Just would also be very nice to use Peter's migration tool to also capture > the history+authors. > (I can provide you with a lis of authors that for the migration tool that > should cover most authors from PetitParser). > > If you're at this, could also help to migrate the PetitSQLite and PetitJava > projects. > > Cheers, > Andrei > > > On Mon, Dec 3, 2018 at 3:41 PM Julien <mailto:julien.delplan...@inria.fr>> wrote: > Hello, > > I’d like to migrate PetitParser (1) on GitHub under moosetechnology > organisation. > > I have a project depending on it and there are some stuff I’d like to fix on > PetitParser 1 ConfigurationOf (which will become a baseline on GitHub). > > Is it ok to migrate it? > > Cheers, > > Julien > > --- > Julien Delplanque > Doctorant à l’Université de Lille > http://juliendelplanque.be/phd.html <http://juliendelplanque.be/phd.html> > Equipe Rmod, Inria > Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq > Numéro de téléphone: +333 59 35 86 40 > > ___ > Moose-dev mailing list > moose-...@list.inf.unibe.ch <mailto:moose-...@list.inf.unibe.ch> > https://www.list.inf.unibe.ch/listinfo/moose-dev > <https://www.list.inf.unibe.ch/listinfo/moose-dev> > ___ > Moose-dev mailing list > moose-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev
[Pharo-dev] Migrate PetitParser (1) on GitHub under moosetechnology organisation?
Hello, I’d like to migrate PetitParser (1) on GitHub under moosetechnology organisation. I have a project depending on it and there are some stuff I’d like to fix on PetitParser 1 ConfigurationOf (which will become a baseline on GitHub). Is it ok to migrate it? Cheers, Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40
Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"
Cool, thanks for all this work ! :-) Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 22 nov. 2018 à 12:00, Esteban Lorenzano a écrit : > > Once we open dev-8.0, yes :) > > Esteban > >> On 22 Nov 2018, at 11:51, Julien > <mailto:julien.delplan...@inria.fr>> wrote: >> >> Hi, >> >> Should we submit PR concerning non-stabilisation changes (like refactoring >> or new features) to another branch like dev-8.0 then? >> >> Cheers, >> >> Julien >> >> --- >> Julien Delplanque >> Doctorant à l’Université de Lille >> http://juliendelplanque.be/phd.html <http://juliendelplanque.be/phd.html> >> Equipe Rmod, Inria >> Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq >> Numéro de téléphone: +333 59 35 86 40 >> >>> Le 22 nov. 2018 à 11:40, Esteban Lorenzano >> <mailto:esteba...@gmail.com>> a écrit : >>> >>> Hi list, >>> >>> Well, subject says pretty much all. >>> We are planning to release Pharo 7.0 very soon now, and while preparing the >>> release process, we came to the conclusion that we will need a branch for >>> version to develop, and because of that we will need to rename what is not >>> “development” to “dev-7.0”. >>> Then, it will be a “dev-8.0” and so on… >>> >>> So, be prepared to submit your PRs to dev-7.0 instead development :) >>> >>> Cheers, >>> Esteban >> >
Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"
Hi, Should we submit PR concerning non-stabilisation changes (like refactoring or new features) to another branch like dev-8.0 then? Cheers, Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 22 nov. 2018 à 11:40, Esteban Lorenzano a écrit : > > Hi list, > > Well, subject says pretty much all. > We are planning to release Pharo 7.0 very soon now, and while preparing the > release process, we came to the conclusion that we will need a branch for > version to develop, and because of that we will need to rename what is not > “development” to “dev-7.0”. > Then, it will be a “dev-8.0” and so on… > > So, be prepared to submit your PRs to dev-7.0 instead development :) > > Cheers, > Esteban
Re: [Pharo-dev] [ANN] The STON Specification
Hello, STON is able to serialise Pharo’s Floats, what do you mean by double ? Additionally, I recently asked Sven if t would be possible to store ScaledDecimals (I think it implements what you call ArbitraryPrecisionFloats) without loss of precision. Before, because STON extends JSON, it was storing all kind of numbers either as float or integer. Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of precision through serialisation as float, what was done before). But I do not know if this change is integrated in recent images yet. Cheers, Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 6 nov. 2018 à 06:58, Shaping a écrit : > > (Having domain problems recently. Please excuse this posting if you have > seen it twice. I've not seen it appear yet on the list.) > > > Can STON be extended to handle Doubles and ArbitraryPrecisionFloats? > > Shaping > > -Original Message- > From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of > David T. Lewis > Sent: Wednesday, October 31, 2018 14:58 > To: Pharo Development List > Subject: Re: [Pharo-dev] [ANN] The STON Specification > > This is very clear and well written. > > Dave > >> Hi, >> >> Since there can never be enough documentation I finally took some time >> to write a more formal description of STON as a data format. >> >> https://github.com/svenvc/ston/blob/master/ston-spec.md >> >> The idea is to let this stabilise a bit and to then update the two >> other documents describing STON, where necessary: >> >> https://github.com/svenvc/ston/blob/master/ston-paper.md >> >> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuc >> cessfulBuild/artifact/book-result/STON/STON.html >> >> Also, the latest changes in STON have to make their way to the Pharo >> image as well. >> >> https://github.com/svenvc/ston >> >> All feedback is welcome. >> >> Sven >> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> > > > > >
Re: [Pharo-dev] Array inspector Items view Selection broken
I can relate. I encountered this bug today and days before as well. I was going to ask about it as well. Cheers, Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 10 oct. 2018 à 21:20, Sven Van Caekenberghe a écrit : > > When you inspect an array, like #(1 2 3), using the Items view in the GT > Inspector, a selection of an item/element results in a sub GT tab with > another array containing that item/element, not the item/element itself as it > should be. > > Anyone else seeing this ? > > Sven
Re: [Pharo-dev] Fraction and ScaledDecimal should be not be serialized as Float in STON format
Sorry, I forgot to answer. This change is indeed really nice. Thank you for it! Cheers, Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 9 oct. 2018 à 21:22, Sven Van Caekenberghe a écrit : > > I decided to add it for real: > > https://github.com/svenvc/ston/commit/9c83e3cc2f00cab83e57f2e10a139d6ecef3cb30 > > add support for Fraction and ScaledDecimal as direct numeric literals (in > STON mode, not in JSON mode) with units tests > >> On 25 Sep 2018, at 14:13, Sven Van Caekenberghe wrote: >> >> >> >>> On 18 Sep 2018, at 16:45, Sven Van Caekenberghe wrote: >>> >>> Of course, we could also extend the basic number parser and allow the >>> native (stored) notation >>> >>> 1/3 >>> 3/2s2 >>> >>> Note how that last one should use the more exact #storeOn: notation, not >>> the #printOn: >>> >>> I'll have to think about this a bit more, as I can really not choose right >>> now. >> >> I am still not sure if we should do this or not, but here is a POC >> implementation of the above. >> >> It implements the following syntax extension (see the class comment of STON >> for the rest). >> >> number >> int >> int denominator >> int denominator scale >> int frac >> int exp >> int frac exp >> >> denominator >> / digits >> >> scale >> s digits >> >> >> STONWriter>>#writeFraction: fraction >> jsonMode >> ifTrue: [ self writeFloat: fraction asFloat ] >> ifFalse: [ >> writeStream >> print: fraction numerator; >> nextPut: $/; >> print: fraction denominator ] >> >> STONWriter>>#writeScaledDecimal: scaledDecimal >> jsonMode >> ifTrue: [ self writeFloat: scaledDecimal asFloat ] >> ifFalse: [ >> writeStream >> print: scaledDecimal numerator; >> nextPut: $/; >> print: scaledDecimal denominator; >> nextPut: $s; >> print: scaledDecimal scale ] >> >> Fraction>>#stonOn: stonWriter >> stonWriter writeFraction: self >> >> ScaledDecimal>>#stonOn: stonWriter >> stonWriter writeScaledDecimal: self >> >> STONReader>>parseNumber >> | negated number | >> negated := readStream peekFor: $-. >> number := self parseNumberInteger. >> (readStream peekFor: $/) >> ifTrue: [ >> number := Fraction numerator: number denominator: self >> parseNumberInteger. >> (readStream peekFor: $s) >> ifTrue: [ number := ScaledDecimal >> newFromNumber: number scale: self parseNumberInteger ] ] >> ifFalse: [ >> (readStream peekFor: $.) >> ifTrue: [ number := number + self >> parseNumberFraction ]. >> ((readStream peekFor: $e) or: [ readStream peekFor: $E >> ]) >> ifTrue: [ number := number * self >> parseNumberExponent ] ]. >> negated >> ifTrue: [ number := number negated ]. >> self consumeWhitespace. >> ^ number >> >> Sven >> > >
Re: [Pharo-dev] [rmod] Float should not implement #to:, #to:by:, etc...
Hello, Ok, I read all the mails. I see your point about not cancelling the possibility to use #to:by: on any Number. However, the remark from David Grandi seems really relevant to me. You can NOT write anything else than a *rational number* when writing a literal using the XXX.XXX pattern. I think it would be legit to generate scaled decimal by default from float literals and to be able to get Float only by either explicitly specify it (#asFloat, etc…) or because of computation that lead to a Float (e.g. the need to approach an irrational number ?). I would be curious to see the impact of such change in the compiler on the system. Maybe a first step is indeed to implement a rule in Renraku to encourage people to use ScaledDecimals. Cheers, Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 19 sept. 2018 à 09:22, Davide Grandi a écrit : > > > 0.0 to: 1.0 by: 0.1 > Receiver and arguments, lexically (the dot), are float BUT > are written as decimal number (zero, one, one tenth). > > I think that in a text you can ONLY write "decimal" numbers or (in bases > other than 10 [or with factors other than 2^x and 5 ?]), at worst, repeating > decimals > (eg 0,1 in base 3 = 1/3 ~ 0.333...), that are ultimately fractions. > > So, may be, if the receiver or an argument is a float the compiler may issue > a warning and compile to non-float, > if receiver or arguments are computed ... there should be a default behaviour. > > Best regards, > > Davide Grandi > (PS : I work mainly in an ERP that has only integers ... and doubles) > > On 18/09/2018 11:52, Guillaume Larcheveque wrote: >> Maybe #to:by: should convert its parameters in Fraction to avoid Floats >> problems (not sure, just an idea) >> >> 2018-09-18 11:25 GMT+02:00 Esteban Lorenzano > <mailto:esteba...@gmail.com>>: >> >>> On 18 Sep 2018, at 11:13, Guillermo Polito >> <mailto:guillermopol...@gmail.com>> wrote: >>> >>> >>> >>> On Tue, Sep 18, 2018 at 11:06 AM Julien >> <mailto:julien.delplan...@inria.fr>> wrote: >>> Hello, >>> >>> I realised that it is possible to create an interval of floats. >>> >>> I think this is bad because, since intervals are computed by successively >>> adding a number, it might result in precision errors. >>> >>> (0.0 to: 1.0 by: 0.1) asArray >>> #(0.0 0.1 0.2 0.30004 0.4 0.5 >>> 0.6001 0.7001 0.8 0.9 1.0) >>> >>> The correct (precise) way to do it would be to use ScaledDecimal: >>> >>> (0.0s1 to: 1.0s1 by: 0.1s1) asArray >>> #(0.0s1 0.1s1 0.2s1 0.3s1 0.4s1 >>> 0.5s1 0.6s1 0.7s1 0.8s1 0.9s1 1.0s1) >>> >>> I opened an issue about it: >>> https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by-etc >>> >>> <https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by-etc> >>> >>> And I’d like to discuss this with you. >>> >>> What do you think? >>> >>> Well, I think it's a matter of balance :) >>> >>> #to:by: is defined in Number. So we could, for example, cancel it in Float. >>> However, people would still be able to do >>> >>> 1 to: 1.0 by: 0.1 >>> >>> Which would still show problems. >> >> Nevertheless, I have seen this a lot of times. >> >> 0.0 to: 1.0 by: 0.1 >> >> Is a common use case. >> >>> >>> And moreover, we could try to do >>> >>> 1 to: 7 by: (Margin fromNumber: 1) >>> >>> And even worse >>> >>> 1 to: Object new by: (Margin fromNumber: 1) >>> >>> I think adding type-validations all over the place is not a good solution, >>> and is kind of opposite to our philosophy... >>> >>> So we should >>> - document the good usages >>> - document the bad ones >>> - and live with the fact that we have a relaxed type system that will fail >>> at runtime :) >> >> yup. >> But not cancel. >> >> Esteban >> >>> >>> Guille >> >> >> >> >> -- >> Guillaume Larcheveque >>
Re: [Pharo-dev] Fraction and ScaledDecimal should be not be serialized as Float in STON format
Hello,Le 18 sept. 2018 à 16:45, Sven Van Caekenberghe <s...@stfx.eu> a écrit :Hi Julien,Good and interesting point.Your summary is correct: STON, inheriting from JSON so to speak, only knowns about integer and float numbers. All other Smalltalk numbers get converted, which results in a loss of type and precision. That might not be a perfect situation, but nobody complained so far.That’s what I guessed to be the reason of this feature. :-)If we would change it, efficiency has to be taken into account: speed/memory efficiency as well as human typing efficiency/complexity. Compatibility, especially between different Smalltalk and other object languages, is also an aspect.Apart from the current approach, the full STON approach could be, for example for 1/3 and 1.5s2Fraction { #numerator:1, #denominator:3 }ScaledDecimal { #numerator:3, #denominator:2, #scale:2}For some types, STON uses shorter notations, either using positional arguments Point [ 1, 2 ]Fraction [ 1, 3 ]ScaledFraction [ 3, 2, 2 ]Or a string argument, when there is a clear external representationDateAndTime [ '2018-09-18T16:39:10.325129+02:00' ]Fraction [ '1/3' ]ScaledFraction [ '3/2s2' ]Of course, we could also extend the basic number parser and allow the native (stored) notation1/33/2s2Note how that last one should use the more exact #storeOn: notation, not the #printOn: I'll have to think about this a bit more, as I can really not choose right now.SvenTell me if you need help to implement this feature, I’ll be happy to contribute! :-)Cheers,Julien---Julien DelplanqueDoctorant à l’Université de Lillehttp://juliendelplanque.be/phd.htmlEquipe Rmod, InriaBâtiment B 40, Avenue Halley 59650 Villeneuve d'AscqNuméro de téléphone: +333 59 35 86 40
[Pharo-dev] Float should not implement #to:, #to:by:, etc...
Hello, I realised that it is possible to create an interval of floats. I think this is bad because, since intervals are computed by successively adding a number, it might result in precision errors. (0.0 to: 1.0 by: 0.1) asArray >>> #(0.0 0.1 0.2 0.30004 0.4 0.5 0.6001 0.7001 0.8 0.9 1.0) The correct (precise) way to do it would be to use ScaledDecimal: (0.0s1 to: 1.0s1 by: 0.1s1) asArray >>> #(0.0s1 0.1s1 0.2s1 0.3s1 0.4s1 0.5s1 0.6s1 0.7s1 0.8s1 0.9s1 1.0s1) I opened an issue about it: https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by-etc <https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by-etc> And I’d like to discuss this with you. What do you think? Cheers, Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40
[Pharo-dev] Fraction and ScaledDecimal should be not be serialized as Float in STON format
Hello, I realised that in the current implementation, when a number is serialised by STON it is either as an integer literal or as a float literal. There is a risk to loose precision, especially if what you serialise is a ScaledDecimal or a fraction. I propose a simple change to fix this: 1. Add STONWriter>>#isInJsonMode method which returns true if the STONWriter wants to write JSON 2. Add: Fraction>>#stonOn: stonWriter stonWriter isInJsonMode ifTrue: [ ^ super stonOn: stonWriter ]. stonWriter writeObject: self streamMap: [ :dictionary | dictionary at: #numerator put: numerator. dictionary at: #denominator put: denominator ] 3. Add: ScaledDecimal>>#stonOn: stonWriter stonWriter isInJsonMode ifTrue: [ ^ super stonOn: stonWriter ]. stonWriter writeObject: self streamMap: [ :dictionary | dictionary at: #numerator put: numerator. dictionary at: #denominator put: denominator. dictionary at: #scale put: scale ] This change has a main drawback, storing fractions and scaled decimal will result in a huge overhead. Maybe for ScaledDecimal we can use Pharo’s literal (e.g. 1.12s2). For fractions I don’t know what literal could be used? Or maybe the overhead is fine? Cheers, Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40
Re: [Pharo-dev] [Pharo 7.0-dev] Build #1249: 22452 Added #labelHeight method.
Seems strange to have the CI failing with this change… --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 16 sept. 2018 à 18:30, ci-pharo-ci-jenki...@inria.fr a écrit : > > There is a new Pharo build available! > > The status of the build #1249 was: FAILURE. > > The Pull Request #1800 was integrated: "22452 Added #labelHeight method." > Pull request url: https://github.com/pharo-project/pharo/pull/1800 > > Issue Url: https://pharo.fogbugz.com/f/cases/22452 > Build Url: > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1249/
[Pharo-dev] PharoLauncher : Image version determination error
Hello, Is there something wrong with the latest Pharo 7.0 32bits image? I got this error from Pharo Launcher: Cannot determine image version: image version file not found! Try to run this command in a shell to get more information on the problem: cd "/Users/julien/Documents/Pharo/vms/private/6521/Pharo.app/Contents/MacOS" && "/Users/julien/Documents/Pharo/vms/private/6521/Pharo.app/Contents/MacOS/Pharo" --headless "/Users/julien/Documents/Pharo/images/RTFExperiment-Iceberg/RTFExperiment-Iceberg.image" eval "(Smalltalk imagePath asFileReference parent) / 'pharo.version' writeStreamDo: [ :stream | |major minor|major := SystemVersion current major. minor := SystemVersion current minor. (major = 6 and: [ SystemVersion current highestUpdate >= 60509 ]) ifTrue: [ minor := 1 ]. stream << major asString; << minor asString ]" When trying to start it. If I run this script in the terminal, nothing is print but the process crashes returning 1 as exit code. Can someone relate this issue as well? Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40
Re: [Pharo-dev] Need help to get a list of Pharo projects with tests
Thanks for all your answers, I’m collecting these projects for the experiment. :-) Peter, > Le 5 juil. 2018 à 21:12, Peter Uhnák a écrit : > > Hi, > > can you please include in the README at the very least how it should be > launched? Looking through the code I eventually found that there's a world > menu entry... but that's not exactly the best way to discovery. Yeah, the GitHub repository is not yet in a good state, the previous mail was not an announcement for the project in fact, I just put the link to show it exists, it’s real… :-) Anyway, you can run it (without the GUI, because there are some bugs in it and I do not focus too much on it for now) using this: [RottenTestsFinder analyze: (RPackage organizer packageNamed: 'Collections-Tests')] on: Warning do: #resume. > > I've ran it on couple of projects, but it didn't show anything apart from > self skip, but if you find something else, I'd be interested to see what it > can detect. In Collection tests you have some rotten tests. :-) BUT, the result are not totally correct right now, it is still under development so do not expect it to work for now. > > https://github.com/peteruhnak?utf8=%E2%9C%93&tab=repositories&q=&type=source&language=smalltalk > > <https://github.com/peteruhnak?utf8=%E2%9C%93&tab=repositories&q=&type=source&language=smalltalk> > > > Also when I filter packages and select one, the test cases list contains some > random unrelated tests. When the filtering is not on, the test cases are > correct. Yeah, I know this bug, the filter of the Spec widget does not work as I expected. If you do not use the filters, it should work well. You can select all tests in the second list using Cmd+a. Cheers, Julien
[Pharo-dev] Need help to get a list of Pharo projects with tests
Hello Pharo community, I am currently working on detecting rotten tests in Pharo projects. Rotten tests are defined as test methods containing one or many assertions in their source code but one or many of these assertions are not executed when the test is run. To have more details on the subject, you can check the research report related to our first definition of these tests freely available on HAL [1]. In this context, we built a test analyser which, given a Pharo package containing tests, finds rotten tests [2]. This analyser is still under development. We would like to extend the experiment of our research report [1] and to analyse more projects in order to get a better understanding of rotten tests. To do that, we need your help. You can help us in two ways: 1. Answer this email with links to one or many open-source Pharo projects containing tests. 2. If you want, provide us private projects or, at least, run our analyser on these private projects and give us back the results. If you want to help us with the second option, send me a mail directly at julien.delplan...@inria.fr <mailto:julien.delplan...@inria.fr>. Thanks in advance. Regards, Julien Delplanque Links: [1]: https://hal.archives-ouvertes.fr/hal-01819302 <https://hal.archives-ouvertes.fr/hal-01819302> [2]: https://github.com/juliendelplanque/RottenTestsFinder/ <https://github.com/juliendelplanque/RottenTestsFinder/> --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40
Re: [Pharo-dev] [ANN] ba-st Web Stack family gets a new member: Willow-Mixpanel and new releases
Hello, I played a little with Willow yesterday evening and it looks really cool. Thanks for this project. Julien --- Julien Delplanque Doctorant à l’Université de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 1 mai 2018 à 15:28, Gabriel Cotelli a écrit : > > Hi, > > We're happy to announce a new member in the Web Stack family hosted at > https://github.com/ba-st/ <https://github.com/ba-st/> : Willow-Mixpanel > <https://github.com/ba-st/Willow-Mixpanel>. > > This is also a multi-release announcement of the following project versions: > Willow-Mixpanel <https://github.com/ba-st/Willow-Mixpanel> v1.0.0 > Provides Integration between Willow <https://github.com/ba-st/Willow/> and > the Mixpanel Javascript API making easy to send events directly from the > browser > HighchartsSt <https://github.com/ba-st/HighchartsSt> v7.0.0 > Updated Highcharts and Highstock JS libraries to version 6.0.7 > Improved Importing Tools > Migrated sources to Tonel > Willow <https://github.com/ba-st/Willow> v8.0.2. Changes since latest > announcement: > Migrate sources to Tonel format > Improve ScrollIntoViewCommand > Updated JQuery to 3.3.1 > Improve libraries test cases to verify the file contents > Fixed Bug #108 <https://github.com/ba-st/Willow/issues/108>: Senders of > #identifier must ensure the component has assigned an id > Added FAQs to documentation > Added an easy way to add additional libraries to a WillowApplication > Added table footer support > Added to interaction interpreters: > show:whileCallingServerToRender: This will replace anIdentifiedWebView > contents with aRenderable in the DOM before doing the server call, and > replace it again with the rendering obtained from the server call response > transform:into: This will replace anIdentifiedWebView content with > aRenderable on the browser side > > Willow-Bootstrap <https://github.com/ba-st/Willow-Bootstrap> v8.0.2 > Improve file deployment tests > Update datepicker plugin to v1.8.0 > Migrated sources to Tonel format > Willow-JQueryUI <https://github.com/ba-st/Willow-JQueryUI> v7.1.0 > Added JQuery UI dialog builder to component supplier > Improve file deployment tests > Migrated sources to Tonel format > Willow-SpinKit <https://github.com/ba-st/Willow-SpinKit> v5.0.2 > Improve file deployment tests > Migrated sources to Tonel format > Willow-Playground <https://github.com/ba-st/Willow-Playground/> v5.0.0 > Improve package tagging and rename some classes to make the code more uniform > Use the new interaction facilities > RenoirSt <https://github.com/ba-st/RenoirSt> v5.0.0 > Migrated sources to Tonel format > Updated dependencies > Find a more detailed changelog and migration instructions on the release > pages of each repository. > > Special thanks to Tim Mackinnon <https://github.com/macta> for the > constructive feedback driving some of the improvements in Willow and > Francisco Ortiz <https://github.com/fortizpenaloza> for the Mixpanel support. > > Anyone interested in joining our ba-st projects <https://github.com/ba-st/> > is welcomed. > > Regards, > Gabriel Cotelli, Maxi Tabacman and all the contributors.
Re: [Pharo-dev] Getting IP address of machine from Pharo
Ok, this one you can get it (for each network interface) via $ ifconfig In the command line. So I guess it should be possible to ask the OS via a FFI call what is the address. I don’t know what is done in Pharo about that. Apparently, on Linux using C, it is possible to get the IP address of an interface via a call to getifaddrs [1]. I don’t know what is the method to do that on Mac OS. Julien Links: [1]: http://man7.org/linux/man-pages/man3/getifaddrs.3.html --- Julien Delplanque Doctorant à l’Université de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 14 mars 2018 à 11:28, Denis Kudriashov a écrit : > > 2018-03-14 11:14 GMT+01:00 Julien <mailto:julien.delplan...@inria.fr>>: > What do you mean by your IP address, on your local network or the one seen by > external servers when you connect to them? > > I need address in my local network. > > > If I remember well, the IP address seen by computers outside your local > network is not the IP address of your actual computer but the one of the > router connecting your local network to the outside web. > > I am not sure you can get the outside IP address without asking it to a > computer outside your local network but I might be wrong. > > Julien > > --- > Julien Delplanque > Doctorant à l’Université de Lille 1 > http://juliendelplanque.be/phd.html <http://juliendelplanque.be/phd.html> > Equipe Rmod, Inria > Bâtiment B 40, Avenue Halley 59650 > <https://maps.google.com/?q=40,+Avenue+Halley+59650+Villeneuve+d'Ascq&entry=gmail&source=g> > Villeneuve > <https://maps.google.com/?q=40,+Avenue+Halley+59650+Villeneuve+d'Ascq&entry=gmail&source=g> > d'Ascq > <https://maps.google.com/?q=40,+Avenue+Halley+59650+Villeneuve+d'Ascq&entry=gmail&source=g> > Numéro de téléphone: +333 59 35 86 40 > >> Le 14 mars 2018 à 11:07, Denis Kudriashov > <mailto:dionisi...@gmail.com>> a écrit : >> >> Hello. >> >> Do we have a way to retrieve IP address from Pharo? >> I tried to use following code: >> >> NetNameResolver addressForName: NetNameResolver localHostName >> >> But it either not works (dialog with retry give-up options) or returns >> localhost 127.0.0.1. >> >> Best regards, >> Denis > >
Re: [Pharo-dev] Getting IP address of machine from Pharo
What do you mean by your IP address, on your local network or the one seen by external servers when you connect to them? If I remember well, the IP address seen by computers outside your local network is not the IP address of your actual computer but the one of the router connecting your local network to the outside web. I am not sure you can get the outside IP address without asking it to a computer outside your local network but I might be wrong. Julien --- Julien Delplanque Doctorant à l’Université de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 14 mars 2018 à 11:07, Denis Kudriashov a écrit : > > Hello. > > Do we have a way to retrieve IP address from Pharo? > I tried to use following code: > > NetNameResolver addressForName: NetNameResolver localHostName > > But it either not works (dialog with retry give-up options) or returns > localhost 127.0.0.1. > > Best regards, > Denis
Re: [Pharo-dev] Iceberg 0.6.8 backported to 6.1
Nice, thank you! Julien --- Julien Delplanque Doctorant à l’Université de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 13 févr. 2018 à 13:33, Esteban Lorenzano a écrit : > > Hi, > > I backported iceberg 0.6.8 to Pharo 6.1, so now it is in sync with the > version on Pharo 7.0 > > Esteban
[Pharo-dev] Point>>#rotateBy:about: has a bad comment
Hello, Concerning this case I just opened: https://pharo.fogbugz.com/f/cases/21329/Point-rotateBy-about-has-a-bad-comment <https://pharo.fogbugz.com/f/cases/21329/Point-rotateBy-about-has-a-bad-comment> I’d like your opinion about it. I just copy in this mail what I said on the case: rotateBy: angle about: center "Even though Point.theta is measured CW, this rotates with the more conventional CCW interpretateion of angle." [...] I think this comment does not explain what this method does. What should be something like: This method returns the point obtained after rotating myself around #center point of an #angle given as parameter. The #angle provided as parameter is interpreted as being in radian. Additionally, I think the name of this method is bad, maybe it should be renamed to something more explicit like #rotateBy:around: or #rotateByRadians:around:. Maybe, if this method is renamed as #rotateByRadians:around:, the method #rotateByDegrees:around: should be added as well. Cheers, Julien --- Julien Delplanque Doctorant à l’Université de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40
Re: [Pharo-dev] [ANN] PharoLauncher v1.1 released!
Cool! I updated my version to this new release. :-)Julien ---Julien DelplanqueDoctorant à l’Université de Lille 1http://juliendelplanque.be/phd.htmlEquipe Rmod, InriaBâtiment B 40, avenue Halley 59650 Villeneuve d'AscqNuméro de téléphone: +333 59 35 86 40 Le 16 janv. 2018 à 21:46, Christophe Demarey <christophe.dema...@inria.fr> a écrit :Hi all,I just released PharoLauncher 1.1. There are now 64-bits versions for Mac and Linux. Jenkins build is now managed through a Jenkins file.Here is the changelog (details on https://github.com/pharo-project/pharo-launcher/issues):New features: #66 new command: import an image into the launcher default image folder #65 new command: remove a template from "Downloaded templates" #64 new command: create a local template from an image and remove the image #57 new option: run an image from a login shell to inherit from shell startup scripts to set up environment variables. #54 It is now possible to run an image anywhere on your file system if you click "launch" and no image is selected #23 Pharo Launcher now has an "about" box giving its description, version and a link to the bug tracker.Improvements: #62 Pharo Launcher should not load default Pharo settings #51 Pharo Launcher now sets the current directory to the directory containing the image (was the VM directory). Avoid confusions in Pharo 7 images.Bux fixes: #60 hardReset option causes troubles to PharoLauncher #56 #, was sent to nil #55 Display name of Pharo 7 images unusable #52 Cannot open a Pharo 2 image #47 Cannot run pharo 50 pre-Spur imagesYou can get platform bundles from files.pharo.org: http://files.pharo.org/pharo-launcher/1.1/Regards,Christophe.
Re: [Pharo-dev] [Ann] Calypso scoped refactoring
This scope list in the widget was definitely something missing in Nautilus. Thanks a lot for this! Julien --- Julien Delplanque Doctorant à l’Université de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 15 janv. 2018 à 12:10, Denis Kudriashov a écrit : > > I finally implemented scopes support for refactorings in Calypso to be able > restrict system changes to particular set of packages or classes. > The new preview tool is copy of old ChangesBrowser with additional scopes > list widget: > > > > In this picture I requested Announcer>>initialize rename and switched scope > to the Announcer package. > > Scopes are filled by browser where refactoring was requested. It is same > logic how method browser receives scopes from original browser. > > When user changes scope all refactoring changes are recomputed. > > It was last dependency of Calypso from Nautilus related packages. Now it can > be loaded without Nautilus. > > Best regards, > Denis
Re: [Pharo-dev] Newsletter content / editors wanted
For the next one you could talk about the solutions created by the community for the Advent Of Code. They will be available there: https://github.com/juliendelplanque/AdventOfCode2017WithPharo <https://github.com/juliendelplanque/AdventOfCode2017WithPharo> --- Julien Delplanque Doctorant à l’Université de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 1 déc. 2017 à 09:15, Marcus Denker a écrit : > > Hi, > > You might know that we are sending out a monthly pharo newsletter, it > contains larger > “mini articles” (e.g. announcements) and small one-line notes for blog posts, > new libraries, > things like that. > > Here is the archive: > > > https://us11.campaign-archive.com/home/?u=6f667565c2569234585a7be77&id=048680a940 > > <https://us11.campaign-archive.com/home/?u=6f667565c2569234585a7be77&id=048680a940> > > Target audience are especially those who no follow the mailing list, but I > think it is interesting > even for us as it is easy to not see all the interesting news. > > If you have content: please send it to me, I collect things over a month and > then we put the > newletter together from that. > > This can be: > > - small (half page) articles abut *your* project! > - an interesting library you found > - a blog post you have written (or read) > > People can even take over for a complete month and do e.g. a themed > newsletter focusing > on one aspect or project. > > Marcus
Re: [Pharo-dev] Moving from mc to tonel?
If you use Traits and want to have Epicea loadable from GitHub on Pharo 6.1, it will not work. There is an issue when you try to load a Trait in Tonel format in the image. --- Julien Delplanque Doctorant à l’Université de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 6 nov. 2017 à 01:42, Martin Dias a écrit : > > Hi all, I'm considering to move Epicea (+Ombu+Hiedra) to github. I read that > tonel is the new format and there is Peter's git-migration, which could be > the tool to do it. > > Is it good idea to move now? > Is it the right tool? > > Bests, > Martín
Re: [Pharo-dev] Advent of code
I’ll write a README with some instructions to avoid clash when merging pull requests. For example, each participant could create a directory with its name and put all his stuff inside it. Julien > Le 22 nov. 2017 à 21:09, Stephane Ducasse a écrit : > > Tx I forked it. > > On Wed, Nov 22, 2017 at 5:38 PM, Julien <mailto:julien.delplan...@inria.fr>> wrote: > Ok I created one [1], maybe if multiple people are playing with me we can > gather the different solutions we get for each puzzle in this repository. > > Julien > > [1]: https://github.com/juliendelplanque/AdventOfCode2017WithPharo > <https://github.com/juliendelplanque/AdventOfCode2017WithPharo> > >> Le 22 nov. 2017 à 16:55, Stephane Ducasse > <mailto:stepharo.s...@gmail.com>> a écrit : >> >> Julien >> >> could you open a github project so that we can do the same as norviq? >> And get a log of the problems and solution? >> >> Stef >> >> On Wed, Nov 22, 2017 at 2:25 PM, Serge Stinckwich >> mailto:serge.stinckw...@gmail.com>> wrote: >> BTW, the Japanese Smalltalk community is doing an advent Calendar every year: >> >> https://qiita.com/advent-calendar/2016/smalltalk >> <https://qiita.com/advent-calendar/2016/smalltalk> >> >> The 2017 edition is in preparation here: >> https://qiita.com/advent-calendar/2017/smalltalk >> <https://qiita.com/advent-calendar/2017/smalltalk> >> >> >> >> On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse > <mailto:stepharo.s...@gmail.com>> wrote: >> Hi pharoers >> >> I would like to know if you would like to participate to >> http://adventofcode.com/2016 <http://adventofcode.com/2016> >> >> For example we could do the same as >> https://github.com/norvig/pytudes/blob/master/ipynb/Advent%20of%20Code.ipynb >> <https://github.com/norvig/pytudes/blob/master/ipynb/Advent%20of%20Code.ipynb> >> >> Stef >> >> >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC/UY1) >> "Programs must be written for people to read, and only incidentally for >> machines to execute." >> http://www.doesnotunderstand.org/ <http://www.doesnotunderstand.org/> > >
Re: [Pharo-dev] Advent of code
Ok I created one [1], maybe if multiple people are playing with me we can gather the different solutions we get for each puzzle in this repository. Julien [1]: https://github.com/juliendelplanque/AdventOfCode2017WithPharo > Le 22 nov. 2017 à 16:55, Stephane Ducasse a écrit : > > Julien > > could you open a github project so that we can do the same as norviq? > And get a log of the problems and solution? > > Stef > > On Wed, Nov 22, 2017 at 2:25 PM, Serge Stinckwich <mailto:serge.stinckw...@gmail.com>> wrote: > BTW, the Japanese Smalltalk community is doing an advent Calendar every year: > > https://qiita.com/advent-calendar/2016/smalltalk > <https://qiita.com/advent-calendar/2016/smalltalk> > > The 2017 edition is in preparation here: > https://qiita.com/advent-calendar/2017/smalltalk > <https://qiita.com/advent-calendar/2017/smalltalk> > > > > On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse <mailto:stepharo.s...@gmail.com>> wrote: > Hi pharoers > > I would like to know if you would like to participate to > http://adventofcode.com/2016 <http://adventofcode.com/2016> > > For example we could do the same as > https://github.com/norvig/pytudes/blob/master/ipynb/Advent%20of%20Code.ipynb > <https://github.com/norvig/pytudes/blob/master/ipynb/Advent%20of%20Code.ipynb> > > Stef > > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC/UY1) > "Programs must be written for people to read, and only incidentally for > machines to execute." > http://www.doesnotunderstand.org/ <http://www.doesnotunderstand.org/>
Re: [Pharo-dev] Advent of code
The 2017 version will be online on 1st December normally. I will participate for sure, I implemented some of the algorithms of 2016 versions and I’d say that Pharo is really cool to do that because of its nice Collections framework (a lot of exercises are about extracting data from/transforming/interpret data-structures provided serialised in a text file). :-) Julien > Le 22 nov. 2017 à 13:29, Stephane Ducasse a écrit : > > Hi pharoers > > I would like to know if you would like to participate to > http://adventofcode.com/2016 > > For example we could do the same as > https://github.com/norvig/pytudes/blob/master/ipynb/Advent%20of%20Code.ipynb > > Stef >
Re: [Pharo-dev] Publishing a book with Pillar
> Le 13 nov. 2017 à 21:01, Stephane Ducasse a écrit : > > Hi guys > > we are working on pillar and we will probably release a new alph version soon. > I'm updating the doc. But I found that the doc I was writing can help > some of you. > > Julien is written a nice booklet on USBdrivers and he told me that > this doc works super well on mac. > > Stef > Thanks for your work on this beautiful project guys. :-) Julien
Re: [Pharo-dev] Baseline question
Hello,
To do my baselines I do the following:
1. I create a subclass of BaselineOf.
2. I create an instance method #baseline:
baseline: spec
spec
for: #common
do: [
self
defineDependencies: spec;
definePackages: spec ]
3. I create the #defineDependencies: instance method (for example in
SFDiff):
defineDependencies: spec
^ spec
project: 'ChangeModel' with: [
spec
className: 'ConfigurationOfFamixDiff';
version: #development;
repository:
'http://smalltalkhub.com/mc/Moose/FamixDiff/main';
loads: 'ChangeModel' ];
project: 'FamixDiff' with: [
spec
className: 'ConfigurationOfFamixDiff';
version: #development;
repository:
'http://smalltalkhub.com/mc/Moose/FamixDiff/main';
loads: 'Core' ];
yourself
4. I create the #definePackages: instance method (still for SFDiff):
definePackages: spec
^ spec
package: 'SimilarityFlooding' with: [ spec requires:
#('ChangeModel') ];
package: 'SimilarityFlooding-Tests' with: [ spec requires:
#('SimilarityFlooding') ];
package: 'SimilarityFlooding-Diff' with: [ spec requires:
#('SimilarityFlooding') ];
package: 'SimilarityFlooding-Diff-Tests' with: [ spec requires:
#('SimilarityFlooding-Diff') ];
package: 'SimilarityFlooding-Evaluator' with: [ spec requires:
#('SimilarityFlooding' 'FamixDiff') ];
package: 'SimilarityFlooding-DiffOrion' with: [ spec requires:
#('SimilarityFlooding-Diff') ];
yourself
Separating the dependencies and package definitions allow me to modify
it easily.
I hope it helps.
Julien
PS: to make a baseline use on another baseline as dependency I put this
kind of source code in #defineDependencies:
spec baseline: 'DependenceName' with: [
spec repository: 'github://user/repositoryname/eventualdirectory' ].
On 01/07/17 14:35, Stephane Ducasse wrote:
Hi
I 'm trying to define a baseline for our project and I defined it as
baseline: spec
spec for: #common do: [ spec
baseline: 'SmaCC' with: [ spec
repository: 'github://ThierryGoubier/SmaCC';
loads: 'SmaCC-GLR-Runtime' ];
package: 'SmaCC-Solidity'
"we could say that SmaccSolidity depends on Smacc-Runtime but I do not
know how to say it"
]
Now I thought that I could try to load it using the following
Metacello new
baseline: 'SmaccSolidity';
repository: 'github://RMODINRIA-Blockchain/SmaCC-Solidity';
load.
But I get an error telling me that the baseline constructor does not
understand load ;(
I read the blog of peter
https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-pharo/
and I'm doing exactly the same so I wonder.
Stef
Re: [Pharo-dev] collection flatCollect: #something VS (collection collect: #something) flattened
On 12/01/17 12:32, Henrik Nergaard wrote: Shouldn't these two code snippets behave the same way? #flatCollect: expects that aBlock returns a collection for each element (see method comment) and only flattens one level, while # flattened expands all sub collections it finds: #( #(1 #(2) ) ) flatCollect: [ :x | x ]. "#(1 #(2))" #( #(1 #(2) ) ) flattened. "#(1 2)" Oh, ok so it's a feature :) Ps. Using a symbol instead of a block reduces performance. [ 1 to: 1e9 do: [ :each | each ] ] timeToRun. "0:00:00:02.463" [ 1 to: 1e9 do: #yourself ] timeToRun. "0:00:00:11.468" Wow, I used symbols to make the example clear but I didn't know that. That's sad, I think it is sexier to use a symbol to do this kind of things. :( Regards, Julien
[Pharo-dev] collection flatCollect: #something VS (collection collect: #something) flattened
Hello everyone, While using #flatCollect: on a collection, I realized that, for example, these two code snippets do not behave the same way: #(1 (1)) flatCollect: #yourself. "Raise an error because the array does not contain only collections" (#(1 (1)) collect: #yourself) flattened "Returns #(1 1) Shouldn't these two code snippets behave the same way? Thanks in advance for your answers. Regards, Julien
Re: [Pharo-dev] consider putting stars on our nice books on github :)
Was already done for some of them. Now done for all of them. :-) On 09/12/16 16:11, stepharong wrote: https://github.com/SquareBracketAssociates/EnterprisePharo https://github.com/SquareBracketAssociates/NumericalMethods https://github.com/SquareBracketAssociates/UpdatedPharoByExample https://github.com/SquareBracketAssociates/BuildingUIWithSpec https://github.com/SquareBracketAssociates/TinyBlogTutorial https://github.com/SquareBracketAssociates/ExploringVMs https://github.com/SquareBracketAssociates/DeepIntoPharo Stef
Re: [Pharo-dev] let's talk about themes (and GLMBrickThemer)
Your new theme looks nice, congratulation! I will probably switch from the dark theme to this one once it will be available. :-) Julien On 01/08/16 11:13, Esteban Lorenzano wrote: Hi, For one of my side-projects, I made a new theme for Pharo (still no name, I was planing to call it “Dark Metal” or something like that. Is a variation on the Dark Theme but “our” dark theme is more brown and this one is more blue (see attached)… I wanted to publish it to push it but then I arrived to an unexpected problem: For Spotter and GTTools in general, theming is not done following current theming approach. Instead, they made a full hierarchy of objects. IMO this is plain bad. I understand the attempt to decouple, but now that means if I want to create a new theme, I need to create my theme object with colors I want and then also I need to create an undetermined number of classes (at least one for each tool, but there is also a hierarchy of things there)… anyway, this DOES NOT scale. Because each tool will have to have a “theme class” for each existing theme… How themes (skins, bah) work in all word is to have a color palette and then tools takes them (they can “play” a bit with this palette, but need to always respect the palette). Then, I will commit a SLICE modifying the “themer” classes to take colors from the current theme (instead of have them hardcoded). But of course, how theme work now is not good because they mix “theme” (how they display) and “skin” (color palette). I will also extract the palette to where should have always been (some kind of a style sheet object)… who also should have been editable in settings so people can tweak their configuration. I didn’t wanted to touch this before, because this will supposedly change with brick, but honestly this will not be ready for Pharo 6 and this is annoying (also, I want to publish my theme and I do not want to add overrides all around :P) cheers, Esteban
Re: [Pharo-dev] State of Pharo in comparison with the "Pharo vision" document
Thanks for all your answer I will use the hints you gave me and eventually come back to you if I need more information. :-) Regards, Julien On 20/07/16 01:44, Ben Coman wrote: On Wed, Jul 20, 2016 at 5:59 AM, Julien Delplanque wrote: Hello everyone, For a university project I need to write a little about Pharo. I found the "Pharo vision" document [1] and I am curious about the actual state of Pharo in comparison with it. I have seen some things on the mailing list but I would like some help to gather the state of each goal described in "Pharo vision" version 1.0. I made a list with the goals and wrote some of the (little) knowledge I have about some elements (I also joined it to this mail in case it is not readable): Goals -> State --- 1. Creation of the Pharo Consortium -> Created 2. Small kernel & validated packages -> ? 3. A Robust and Extensible System Events -> ? 4. Rewrite of Filesystem/Streams -> ?/XStream? 5. Announcements and Ephemerons -> ? 6. UI Canvas for Zoomable Interfaces -> Bloc? 7. Bootstrap of the Core -> ? 8. Fully parametrized compiler tool chain -> ? 9. Packages as real objects -> ? 10. Package Meta-Data -> PackageManifest? 11. Less Model Clutter and Duplication -> ? 12. Building and Reusing UI Logic -> Spec? 13. New Network Layer -> ? 14. Serializers -> Fuel 15. SystemChangeNotifier replacement -> ? 16. Cleaning Morphic -> Still valid? (asking because of Bloc existance) 17. Everybody should be able to compile VMs -> ? 18. VMs identification and regression testing -> ? 19. One Unified FFI framework -> Created and still being enhanced 20. 64 Bits -> I saw the screenshot on Twitter but what is the state now? 21. New Object Formats -> ? If some of you know the state of one or many of these project and have the time to give me some information about it/them, I would be really grateful. Thanks in advance, Julien Links: [1]: https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf You should be able to get some answers from... https://github.com/pharo-project/pharo-changelogs Can you fill in yourself what answers you can extract from that - for checking, and letting people focus on where there remain gaps in your questions. cheers -ben
[Pharo-dev] State of Pharo in comparison with the "Pharo vision" document
Hello everyone, For a university project I need to write a little about Pharo. I found the "Pharo vision" document [1] and I am curious about the actual state of Pharo in comparison with it. I have seen some things on the mailing list but I would like some help to gather the state of each goal described in "Pharo vision" version 1.0. I made a list with the goals and wrote some of the (little) knowledge I have about some elements (I also joined it to this mail in case it is not readable): Goals -> State --- 1. Creation of the Pharo Consortium -> Created 2. Small kernel & validated packages -> ? 3. A Robust and Extensible System Events -> ? 4. Rewrite of Filesystem/Streams -> ?/XStream? 5. Announcements and Ephemerons -> ? 6. UI Canvas for Zoomable Interfaces -> Bloc? 7. Bootstrap of the Core -> ? 8. Fully parametrized compiler tool chain -> ? 9. Packages as real objects -> ? 10. Package Meta-Data -> PackageManifest? 11. Less Model Clutter and Duplication -> ? 12. Building and Reusing UI Logic -> Spec? 13. New Network Layer -> ? 14. Serializers -> Fuel 15. SystemChangeNotifier replacement -> ? 16. Cleaning Morphic -> Still valid? (asking because of Bloc existance) 17. Everybody should be able to compile VMs -> ? 18. VMs identification and regression testing -> ? 19. One Unified FFI framework -> Created and still being enhanced 20. 64 Bits -> I saw the screenshot on Twitter but what is the state now? 21. New Object Formats -> ? If some of you know the state of one or many of these project and have the time to give me some information about it/them, I would be really grateful. Thanks in advance, Julien Links: [1]: https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf Goals | State 1. Creation of the Pharo Consortium | Created 2. Small kernel & validated packages | ? 3. A Robust and Extensible System Events | ? 4. Rewrite of Filesystem/Streams | ?/XStream? 5. Announcements and Ephemerons | ? 6. UI Canvas for Zoomable Interfaces | Bloc? 7. Bootstrap of the Core | ? 8. Fully parametrized compiler tool chain| ? 9. Packages as real objects | ? 10. Package Meta-Data | PackageManifest? 11. Less Model Clutter and Duplication| ? 12. Building and Reusing UI Logic | Spec? 13. New Network Layer | ? 14. Serializers | Fuel 15. SystemChangeNotifier replacement | ? 16. Cleaning Morphic | Still valid? (asking because of Bloc existance) 17. Everybody should be able to compile VMs | ? 18. VMs identification and regression testing | ? 19. One Unified FFI framework | Created 20. 64 Bits | ? 21. New Object Formats| ?
Re: [Pharo-dev] Help with bugfix process
For future reader, it was a problem with UUID generation (there is right now an issue about it [1]), I used NeoUUID and it works see [2][3]. Julien Links: [1]: https://pharo.fogbugz.com/f/cases/17544/UUIDs-are-not-so-unique [2]: http://forum.world.st/Need-help-with-Monkey-Removing-Object-gt-gt-name-td4875610.html [3]: http://mc.stfx.eu/Neo/ On 07/02/16 14:04, Julien Delplanque wrote: I just tried using Lubuntu 32 bits on Virtualbox and I still have the same problem... Is it possible that the problem is something else? Julien On 07/02/16 13:41, Julien Delplanque wrote: Ok I will try this :-). Julien On 07/02/16 13:36, Nicolai Hess wrote: Yes, that should work. Am 07.02.2016 1:33 nachm. schrieb "Julien Delplanque" : I do not have a real 32bit machine available, would it be ok to use a virtual 32bit machine? Julien On 07/02/16 13:26, Nicolai Hess wrote: No, you did it right, and it should work that way. At the Moment, we have a problem with uuid genetation on Linux 64bit. Can you try to recreate and resubmit the change on a 32bit Machine? Am 07.02.2016 1:05 nachm. schrieb "Julien Delplanque" : Hello, I am trying to submit a simple enhancement to WindowModel (spec) by adding #activate message [1]. I follow the process described here [2]. The problem is that when I commit my Slice in Pharo50Inbox, it uploads my changes but when I try to load my slice (in a fresh image) I have some strange things happening: I try to load my slice by: 1. Opening Monticello browser. 2. Selecting Pharo50Inbox in the right lists. 3. I click on 'Open' button. 4. I search for my slice in the right list of the window opened. Then, there are two strange things: 1. I can see my slice (with the right name) but when I try to load it using the button 'Load', it does nothing and if I click on changes it shows nothing. 2. The data displayed in the text field on the bottom of the window is wrong, the author is not my username, the package name is not the same as displayed in the right list and the commit message is not my commit message (see attached image). Am I doing something wrong? I think I follow the process correctly so I do not understand what is going on... I already submitted the fix twice and I am sorry if it creates unwanted work for someone. :-( Thanks in advance for the help, Julien [1]: https://pharo.fogbugz.com/f/cases/17528 [2]: http://pharo.org/contribute-propose-fix
Re: [Pharo-dev] UUIDs are not so unique [WAS] Removing Object>>name
Hello, Looks like I have the same problem as I was saying in another thread [1]. I tried to use NeoUUID and I was able to commit my change. I use Archlinux on a 64bit machine: $ uname -a Linux msi 4.4.1-2-ARCH #1 SMP PREEMPT Wed Feb 3 13:12:33 UTC 2016 x86_64 GNU/Linux Regards, Julien Link: [1]: http://forum.world.st/Help-with-bugfix-process-td4876210.html On 08/02/16 16:20, Guille Polito wrote: Yes, creepy. However, I do not know if this is reproducible from some other machine/environment or just in mine, as nobody told so... On 02/08/2016 02:22 PM, Stephan Eggermont wrote: On 08-02-16 14:13, Guille Polito wrote: The thing is that it is not a monkey problem. The monkey asks Smalltalkhub for the right file, but SmalltalkHub retrieves the wrong mcz. And that's because Smalltalkhub associates a commit to an mcz file by the UUID of the commit. So we lost source code? A slice in the inbox that has a duplicate UUID? Stephan
Re: [Pharo-dev] Help with bugfix process
I just tried using Lubuntu 32 bits on Virtualbox and I still have the same problem... Is it possible that the problem is something else? Julien On 07/02/16 13:41, Julien Delplanque wrote: Ok I will try this :-). Julien On 07/02/16 13:36, Nicolai Hess wrote: Yes, that should work. Am 07.02.2016 1:33 nachm. schrieb "Julien Delplanque" : I do not have a real 32bit machine available, would it be ok to use a virtual 32bit machine? Julien On 07/02/16 13:26, Nicolai Hess wrote: No, you did it right, and it should work that way. At the Moment, we have a problem with uuid genetation on Linux 64bit. Can you try to recreate and resubmit the change on a 32bit Machine? Am 07.02.2016 1:05 nachm. schrieb "Julien Delplanque" : Hello, I am trying to submit a simple enhancement to WindowModel (spec) by adding #activate message [1]. I follow the process described here [2]. The problem is that when I commit my Slice in Pharo50Inbox, it uploads my changes but when I try to load my slice (in a fresh image) I have some strange things happening: I try to load my slice by: 1. Opening Monticello browser. 2. Selecting Pharo50Inbox in the right lists. 3. I click on 'Open' button. 4. I search for my slice in the right list of the window opened. Then, there are two strange things: 1. I can see my slice (with the right name) but when I try to load it using the button 'Load', it does nothing and if I click on changes it shows nothing. 2. The data displayed in the text field on the bottom of the window is wrong, the author is not my username, the package name is not the same as displayed in the right list and the commit message is not my commit message (see attached image). Am I doing something wrong? I think I follow the process correctly so I do not understand what is going on... I already submitted the fix twice and I am sorry if it creates unwanted work for someone. :-( Thanks in advance for the help, Julien [1]: https://pharo.fogbugz.com/f/cases/17528 [2]: http://pharo.org/contribute-propose-fix
Re: [Pharo-dev] Help with bugfix process
Ok I will try this :-). Julien On 07/02/16 13:36, Nicolai Hess wrote: Yes, that should work. Am 07.02.2016 1:33 nachm. schrieb "Julien Delplanque" : I do not have a real 32bit machine available, would it be ok to use a virtual 32bit machine? Julien On 07/02/16 13:26, Nicolai Hess wrote: No, you did it right, and it should work that way. At the Moment, we have a problem with uuid genetation on Linux 64bit. Can you try to recreate and resubmit the change on a 32bit Machine? Am 07.02.2016 1:05 nachm. schrieb "Julien Delplanque" : Hello, I am trying to submit a simple enhancement to WindowModel (spec) by adding #activate message [1]. I follow the process described here [2]. The problem is that when I commit my Slice in Pharo50Inbox, it uploads my changes but when I try to load my slice (in a fresh image) I have some strange things happening: I try to load my slice by: 1. Opening Monticello browser. 2. Selecting Pharo50Inbox in the right lists. 3. I click on 'Open' button. 4. I search for my slice in the right list of the window opened. Then, there are two strange things: 1. I can see my slice (with the right name) but when I try to load it using the button 'Load', it does nothing and if I click on changes it shows nothing. 2. The data displayed in the text field on the bottom of the window is wrong, the author is not my username, the package name is not the same as displayed in the right list and the commit message is not my commit message (see attached image). Am I doing something wrong? I think I follow the process correctly so I do not understand what is going on... I already submitted the fix twice and I am sorry if it creates unwanted work for someone. :-( Thanks in advance for the help, Julien [1]: https://pharo.fogbugz.com/f/cases/17528 [2]: http://pharo.org/contribute-propose-fix
Re: [Pharo-dev] Help with bugfix process
I do not have a real 32bit machine available, would it be ok to use a virtual 32bit machine? Julien On 07/02/16 13:26, Nicolai Hess wrote: No, you did it right, and it should work that way. At the Moment, we have a problem with uuid genetation on Linux 64bit. Can you try to recreate and resubmit the change on a 32bit Machine? Am 07.02.2016 1:05 nachm. schrieb "Julien Delplanque" : Hello, I am trying to submit a simple enhancement to WindowModel (spec) by adding #activate message [1]. I follow the process described here [2]. The problem is that when I commit my Slice in Pharo50Inbox, it uploads my changes but when I try to load my slice (in a fresh image) I have some strange things happening: I try to load my slice by: 1. Opening Monticello browser. 2. Selecting Pharo50Inbox in the right lists. 3. I click on 'Open' button. 4. I search for my slice in the right list of the window opened. Then, there are two strange things: 1. I can see my slice (with the right name) but when I try to load it using the button 'Load', it does nothing and if I click on changes it shows nothing. 2. The data displayed in the text field on the bottom of the window is wrong, the author is not my username, the package name is not the same as displayed in the right list and the commit message is not my commit message (see attached image). Am I doing something wrong? I think I follow the process correctly so I do not understand what is going on... I already submitted the fix twice and I am sorry if it creates unwanted work for someone. :-( Thanks in advance for the help, Julien [1]: https://pharo.fogbugz.com/f/cases/17528 [2]: http://pharo.org/contribute-propose-fix
Re: [Pharo-dev] [ANN] Multiple Desktop support for Pharo 5
When changing the desktop, windows opened before where not clickable anymore like if they where a part of the "wallpaper". Julien On 27/08/15 18:52, H. Hirzel wrote: Julien, could you please describe the problem you had in Pharo 4.0 with more details? --Hannes On 8/27/15, Julien Delplanque wrote: On 27/08/15 11:42, H. Hirzel wrote: On 8/27/15, Torsten Bergmann wrote: Hi Julien, sorry for "hijacking" the topic. But I got some time left while traveling allowing me to put my recommended puzzle pieces together myself and as I wrote the code was less time consuming compared to the article. The article should help others to investigate in the goodies code and learn how to do own inspector extensions, spotter models, ... in recent Pharo now. If there is something wrong with the implementation feel free to send me comments/corrections. Also note that the project on STHub is open for commits, so if you find something missing please add it. I would like to keep the "multiple desktops" metaphor instead of "multiple worlds" as it better fits what people know and expect. +1 Additional info: Meanwhile the job run that checks the configurations for the Catalog Browser. So in a fresh and updated Pharo 5 image you can just: - hit SHIFT + ENTER to open the default Spotter - enter "DesktopManager" as a search term to find the project automagically - hit enter to load it So there is no need to rember cumbersome Gofer scripts anymore. Just type and go. After loading you can use the tool as written before: - check the world menu "Desktop" - you can press CTRL + D and then CTRL + A (= Desktop Add) to add a new desktop - you can press CTRL + D and then CTRL + D (= Desktop Desktop) to open the overview (custom spotter for desktop selection) - you can press CTRL + D and then CTRL + P (= Desktop Previous) to navigate to the previous desktop - you can press CTRL + D and then CTRL + N (= Desktop Next) to navigate to the next desktop You can also use the world menu (see another screenshot attached). Hope it will become useful to others as well. We should have cared already back in 2010/2011 when Jochen and Sean raised the issue. On the other side with the nice moldable GT tools introduced now in Pharo 4/5 it was really easy to implement. Does this mean that it is available in Pharo 4 as well? I tried it on pharo 4 and it doesn't works, it has the same problem as the one I had when implementing my version. Julien
Re: [Pharo-dev] [ANN] Multiple Desktop support for Pharo 5
On 27/08/15 11:42, H. Hirzel wrote: On 8/27/15, Torsten Bergmann wrote: Hi Julien, sorry for "hijacking" the topic. But I got some time left while traveling allowing me to put my recommended puzzle pieces together myself and as I wrote the code was less time consuming compared to the article. The article should help others to investigate in the goodies code and learn how to do own inspector extensions, spotter models, ... in recent Pharo now. If there is something wrong with the implementation feel free to send me comments/corrections. Also note that the project on STHub is open for commits, so if you find something missing please add it. I would like to keep the "multiple desktops" metaphor instead of "multiple worlds" as it better fits what people know and expect. +1 Additional info: Meanwhile the job run that checks the configurations for the Catalog Browser. So in a fresh and updated Pharo 5 image you can just: - hit SHIFT + ENTER to open the default Spotter - enter "DesktopManager" as a search term to find the project automagically - hit enter to load it So there is no need to rember cumbersome Gofer scripts anymore. Just type and go. After loading you can use the tool as written before: - check the world menu "Desktop" - you can press CTRL + D and then CTRL + A (= Desktop Add) to add a new desktop - you can press CTRL + D and then CTRL + D (= Desktop Desktop) to open the overview (custom spotter for desktop selection) - you can press CTRL + D and then CTRL + P (= Desktop Previous) to navigate to the previous desktop - you can press CTRL + D and then CTRL + N (= Desktop Next) to navigate to the next desktop You can also use the world menu (see another screenshot attached). Hope it will become useful to others as well. We should have cared already back in 2010/2011 when Jochen and Sean raised the issue. On the other side with the nice moldable GT tools introduced now in Pharo 4/5 it was really easy to implement. Does this mean that it is available in Pharo 4 as well? I tried it on pharo 4 and it doesn't works, it has the same problem as the one I had when implementing my version. Julien
