- Pharo-users - lists.pharo.org

Re: [Pharo-users] [ALERT] Pharo by Example version 5 is about to be released

by Nicolai Hess

2016-10-27 13:32 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > In case someone missed it I will be doing a release for version 5 (pharo > version = pbe version) this weekend , since we had Pharo 7 initiated few > days ago. > > Essentially that means that the repo will be tagged for version 5, which > means a git commit is associated as a last commit for that version and > there will be a frozen release - download for Pharo by Example version 5. > After that we move to Pharo By Example version 6 or PBE6 for short > > The repo wont change otherwise and the process of submitting commits, pull > requests and issues remains the same. > > If you have found a flaw of any sort in the documentation , please open an > issue in the github issue tracker that can be found here > > https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues > > I will try to fix any problem reported but if I cannot , the fix will have > to move to version 6 > > As always thanks to all people contributing into the impossible .... > making Pharo more amazing > > If you want to contribute feel free to do so with a pull request. > > Does not matter if you are beginner because even minor corrections like > correcting mistakes in the grammar or content of the text, updated > pictures, or just a few lines of extra info are more than enough and more > than welcomed. Many Pharo beginners have already done so . > > -Salute to fellow Guardians of The Light > Fix Basic Classes note about Character, as they are now immediates like SmallInteger https://github.com/SquareBracketAssociates/UpdatedPharoByExample/pull/181

Nov. 8, 2016

Re: [Pharo-users] [ALERT] Pharo by Example version 5 is about to be released

by Nicolai Hess

Another pulll request https://github.com/SquareBracketAssociates/UpdatedPharoByExample/pull/180 But I messed this one up. It contains the commits from the other pull request. I can fix this (later) or maybe it can just be merged (can I remove a commit from a branch with githubs web-interface(!) ? 2016-11-08 1:00 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-11-07 8:47 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> Am 06.11.2016 21:04 schrieb "Dimitris Chloupis" <kilon.alios(a)gmail.com>: >> > >> > yeah as I said the chapter needs a complete rewrite. I am not even it >> is necessary to exist separately. >> > >> > On Sun, Nov 6, 2016 at 9:27 PM Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >> >> >> 2016-11-03 15:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> >> >>> >> >>> >> >>> 2016-11-03 15:02 GMT+01:00 stepharo <stepharo(a)free.fr>: >> >>>> >> >>>> Hi nicolai >> >>>> >> >>>> I started to work on the reflection chapter. >> >>> >> >>> >> >>> >> >>> The reflection chapter (and maybe some other too) could new some new >> screenshots. >> >> >> >> >> >> Actually, the reflection chapter needs some more rewrites (not only >> updated screenshots). Some examples just aren't >> >> applicable anymore because we don't have refactoring browser >> preinstalled and although Nautilus can do alot, its missing >> >> the full set of menus for creating scoped environments. >> >> I'll try to rewrite those parts. >> > pull request for this c hapter: > > https://github.com/SquareBracketAssociates/UpdatedPharoByExample/pull/179 > > In short: > updated screenshots > replace some more "explore/explorer" by inspect/inspector > rewrote the RefactoringBrowser parts, use RBBrowserEnvironment insteand of > BrowserEnvironment > fix some differences in LoggingProxy (something had changed in > ProtoObject/Object implementation), some methods like #rect: are renamed in > the actual Pharo 5.0 image. > #haltIf: was broken, as the example with add: / testAdd: traps into an > infinite loop because we now call add: everytime we lookup the add: sender > I replaced this with an example that uses Morph>>#openInWorld instead of > OrderedCollection>>#add: > Replaced MethodContext by Context as the name changed in Pharo 5. Added a > description why we call the inspector on thisContext a "poor mans debugger" > :-) > fix some changed SystemNavigation methods. > Some code examples show the in image method version that had changed > (other names or otherwise refactored). > > so far. But I'll do another pass > > >> >> >> >>>> >> >>>> Now hacking PharoDoc :) >> >>>> >> >>>> Stef >> >>>> >> >>>> >> >>>> Le 3/11/16 Ã 14:29, Nicolai Hess a Ã©crit : >> >>>>> >> >>>>> >> >>>>> >> >>>>> 2016-10-27 13:32 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com >> >: >> >>>>>> >> >>>>>> In case someone missed it I will be doing a release for version 5 >> (pharo version = pbe version) this weekend , since we had Pharo 7 initiated >> few days ago. >> >>>>>> >> >>>>>> Essentially that means that the repo will be tagged for version 5, >> which means a git commit is associated as a last commit for that version >> and there will be a frozen release - download for Pharo by Example version >> 5. After that we move to Pharo By Example version 6 or PBE6 for short >> >>>>>> >> >>>>>> The repo wont change otherwise and the process of submitting >> commits, pull requests and issues remains the same. >> >>>>>> >> >>>>>> If you have found a flaw of any sort in the documentation , please >> open an issue in the github issue tracker that can be found here >> >>>>>> >> >>>>>> https://github.com/SquareBracketAssociates/UpdatedPharoByExa >> mple/issues >> >>>>>> >> >>>>>> I will try to fix any problem reported but if I cannot , the fix >> will have to move to version 6 >> >>>>>> >> >>>>>> As always thanks to all people contributing into the impossible >> .... making Pharo more amazing >> >>>>>> >> >>>>>> If you want to contribute feel free to do so with a pull request. >> >>>>>> >> >>>>>> Does not matter if you are beginner because even minor corrections >> like correcting mistakes in the grammar or content of the text, updated >> pictures, or just a few lines of extra info are more than enough and more >> than welcomed. Many Pharo beginners have already done so . >> >>>>>> >> >>>>>> -Salute to fellow Guardians of The Light >> >>>>> >> >>>>> >> >>>>> I found some problems, but I don't have time to report/fix them >> now, I 'll try to report them >> >>>>> later (today or tomorrow). >> >>>>> >> >>>>> >> >>>> >> >>> >> >> I know fixed most text in the chapter. At least there are no notes on >> tools that aren't there anymore and I cut those things that aren't true >> anyone. >> But I would like to do some more pass over it. >> Instead of just cutting, we could add some new things. >> Explaing the RB-Pattern syntax is maybe to much. But I would like to add >> it. >> Maybe I'll put some notes on criticbrower and QA. >> > >

Nov. 8, 2016

Re: [Pharo-users] about balkanisation

by Dale Henrichs

On 11/7/16 11:42 AM, Nicolas Passerini wrote: > > 2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>>: > > Thierry, If I'm not mistaken, Esteban is referring to the fact > that in FileTree we are still using Monticello to do the load > of the packages and even when we are running metadataless, we > end creating fake meta data to simulate an mcz ... you and I > have had conversations about ways to eliminate this > "requirement" because it is meaningless in a git context ... > > > Yes, this I understood. I do believe that what I suggested at one > point (have the ability to compare versions with an > 'isAncestorOf') would be very nice for that transition (work in > mcz as well as on git with/without metadata). > > > I would like to listen to your ideas about this topic, but I am not > sure it is possible to achieve that compatibility. In fact we tried to > do it for Iceberg and at some point we decided to abort it. > > On one side, trying to re-create monticello sequential file numbers in > git is simply not possible, at least in a reliable way. On the other > side, loading the graph of package versions and dependencies is really > slow for big repositories (such as pharo-core), once we removed that > requirement Iceberg got like 100x faster. I agree that the git-oriented tools should not go ot of their may to conform to the MC model .. as you say it just does not fit ... but many of the standard operations that are performed can be performed on both git and mcz repositories without forcing both of the models to share identical implementations ... in image tools should distinguish between mcz and git projects and dispatch the standard operations to the appropriate repository --- and this si the spot where the handling changes based upon the repository model ... Dale

Nov. 8, 2016

Re: [Pharo-users] about balkanisation

by Dale Henrichs

On 11/7/16 11:30 AM, Thierry Goubier wrote: > Hi Dale, > > 2016-11-07 12:03 GMT+01:00 Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>>: > > > > On 11/7/16 7:15 AM, Thierry Goubier wrote: >> >> >> 2016-11-07 11:05 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>>: >> >> >>> On 7 Nov 2016, at 10:03, Thierry Goubier >>> <thierry.goubier(a)gmail.com >>> <mailto:thierry.goubier@gmail.com>> wrote: >>> >>> Hi Esteban, >>> >>> I cut out the rest, because I agree with all your points, >>> except for... >>> >>> 2016-11-07 9:55 GMT+01:00 Esteban Lorenzano >>> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >>> >>> [ ... ] >>> >>> Replacing Monticello with git goes in this direction: >>> >>> [ ... ] >>> >>> >>> And this one I don't understand. A smooth, git / iceberg >>> oriented transition over Monticello/Metacello is perfectly >>> doable... As Dale explained. A nice Iceberg gui reworking / >>> making git usable is perfect. >> >> Wellâ¦ I disagree with this. >> All my experience says the opposite: this is a convenience >> usage that in the long way does not match (the thing that we >> simulate mcz packages do not workâ¦ and makes things a lot >> harder to maintain later). >> Nico has worked a lot on this, maybe he has something to say. >> >> >> I'd like to. Simulating mcz? That I don't get it. > Thierry, If I'm not mistaken, Esteban is referring to the fact > that in FileTree we are still using Monticello to do the load of > the packages and even when we are running metadataless, we end > creating fake meta data to simulate an mcz ... you and I have had > conversations about ways to eliminate this "requirement" because > it is meaningless in a git context ... > > > Yes, this I understood. I do believe that what I suggested at one > point (have the ability to compare versions with an 'isAncestorOf') > would be very nice for that transition (work in mcz as well as on git > with/without metadata). II think that the work that you did with gitfiletree was very influential in making git a realistic option for the Pharo community and I think that the choices you made were excellent, but I think that for a transition it is important that git be presented as itself more fully and expose some of the features that set git apart (project/package/class/method diffs; multi-package commits; etc.) ... but I also feel that Monticello does not need to be diluted --- the existing Monticello tools should remain in place for the forseeable future ... > > > With the work that Richard Sargent did on the > CypressReferenceImplementation, I would prefer to say that Cypress > can provide an Alternative to Monticello rather than replace it > ... the CypressReferenceImplementation includes a package loader > so it isn't necessary to convert Filetree format on disk to Mcz > format in the image --- without all of the ancestry, "latest > version stuff" and package-cache the loading process becomes much, > much simpler... > > I think that both Monticello and Cypress can live together in the > image ... > > > For me, MC is also the code / diff model behind: will Cypress rewrites > all that too? Well Cypress is not that much of a rewrite ... Cypress definitions are closely based upon the Monticello definition model... snapshots and loading based on comparing the snapshot of the repository against the snapshot of the image are also closely based on Monticello ... The differences are in the fact that Cypress packages do not have ancestry, author names or version numbers: - the ancestry and author is recorded and managed by git (or svn or hg) - there is only one version of a package in a fieltree repo, so there is no need to sort packages by version number to fine the "latest version" So Cypress is more of a "take all of the really good parts of Monticello while dropping the bits that are handled better by git" than it is a complete _rewrite_ ... > > > I have created a version of Metacello that uses Monticello OR > Cypress and I expect to eventually (in the next several months --- > it doesn't take that long, but I've got other things on my plate) > to have a version of Metacello that uses Monticello AND/OR Cypress > again I think that smooth transitions (that may take a long time) > are better supported in this fashion than to draw a line in the > sand and force the usage of one OR the other ... > > > As long as Cypress behaves as a MC repository and fits into the same > API, I really don't see where is the difficulty. As we are saying now, > adding a type of repository / emulating the MC overall API is no real > difficulty in itself and isolates one from all the project management > issues (because that means Metacello, ConfigurationOf and BaselineOf > just keep working as usual). There are api differences between MC and Cypress ... MC has ancestry and package numbers while Cypress does not ... but I don;t think that these are major items ... I have yet to try to merge MC and Cypress in the same Metacello code base and I have yet to look closely at the requirements for Cypress Package Browser tool, but I know that the Cypress Package Browser will be much simpler ... But the goal for Metacello is that individual developers will be able to choose the repository/package model that best fits their work flow and portability needs ... > We need to get the MC repository API to evolve a bit, in part to > handle the "save multiple packages, do one commit without using > package dependencies." required now, and also to expose more of the > repository organisation (remotes, branches) for the GUI above. And > remove some of the things saying "I'm MC trying to do Metacello's job". yes I think this is the area where a Metallo Project Browser comes into play. The technology for committing the dirty packages in a a ConfigurationOf has been around for quite awhile, but a tool that unifies the "multi-package" commit for ConfigurationOf and BaselineOf hasn't popped out of the wood work ... > > What is a bit annoying, really, is this talk of rewriting everything > where some of the pieces (the project browsing you're talkin about, > for example) is already there in the image, just not exposed. Well I am annoyed as well .. I would say that perhaps we are in screaming agreement ... I've said that I don't think it's a lot of work to do the project-centric tool. but a project-centric tool that encompasses both ConfigurationOf and BaselineOf will expose the features that "are already there" > > I'm trying to code a little something for that... stay tuned for a > screenshot soon. Cool:) Dale

Nov. 8, 2016

Re: [Pharo-users] [ALERT] Pharo by Example version 5 is about to be released

by Damien Pollet

On 7 November 2016 at 10:22, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > My opinion is not that themes are not important, but that it looks out of > context in this chapter. > Also think of the print version. The print quality via Lulu is not great for grayscale images, so screenshots in light text over dark background will not be very nice to look at or could even be unreadable if the contrast is too low.

Nov. 8, 2016

Re: [Pharo-users] [ALERT] Pharo by Example version 5 is about to be released

by Nicolai Hess

2016-11-07 8:47 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > Am 06.11.2016 21:04 schrieb "Dimitris Chloupis" <kilon.alios(a)gmail.com>: > > > > yeah as I said the chapter needs a complete rewrite. I am not even it is > necessary to exist separately. > > > > On Sun, Nov 6, 2016 at 9:27 PM Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> > >> 2016-11-03 15:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >>> > >>> > >>> > >>> 2016-11-03 15:02 GMT+01:00 stepharo <stepharo(a)free.fr>: > >>>> > >>>> Hi nicolai > >>>> > >>>> I started to work on the reflection chapter. > >>> > >>> > >>> > >>> The reflection chapter (and maybe some other too) could new some new > screenshots. > >> > >> > >> Actually, the reflection chapter needs some more rewrites (not only > updated screenshots). Some examples just aren't > >> applicable anymore because we don't have refactoring browser > preinstalled and although Nautilus can do alot, its missing > >> the full set of menus for creating scoped environments. > >> I'll try to rewrite those parts. > pull request for this c hapter: https://github.com/SquareBracketAssociates/UpdatedPharoByExample/pull/179 In short: updated screenshots replace some more "explore/explorer" by inspect/inspector rewrote the RefactoringBrowser parts, use RBBrowserEnvironment insteand of BrowserEnvironment fix some differences in LoggingProxy (something had changed in ProtoObject/Object implementation), some methods like #rect: are renamed in the actual Pharo 5.0 image. #haltIf: was broken, as the example with add: / testAdd: traps into an infinite loop because we now call add: everytime we lookup the add: sender I replaced this with an example that uses Morph>>#openInWorld instead of OrderedCollection>>#add: Replaced MethodContext by Context as the name changed in Pharo 5. Added a description why we call the inspector on thisContext a "poor mans debugger" :-) fix some changed SystemNavigation methods. Some code examples show the in image method version that had changed (other names or otherwise refactored). so far. But I'll do another pass > >> > >>>> > >>>> Now hacking PharoDoc :) > >>>> > >>>> Stef > >>>> > >>>> > >>>> Le 3/11/16 Ã 14:29, Nicolai Hess a Ã©crit : > >>>>> > >>>>> > >>>>> > >>>>> 2016-10-27 13:32 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com > >: > >>>>>> > >>>>>> In case someone missed it I will be doing a release for version 5 > (pharo version = pbe version) this weekend , since we had Pharo 7 initiated > few days ago. > >>>>>> > >>>>>> Essentially that means that the repo will be tagged for version 5, > which means a git commit is associated as a last commit for that version > and there will be a frozen release - download for Pharo by Example version > 5. After that we move to Pharo By Example version 6 or PBE6 for short > >>>>>> > >>>>>> The repo wont change otherwise and the process of submitting > commits, pull requests and issues remains the same. > >>>>>> > >>>>>> If you have found a flaw of any sort in the documentation , please > open an issue in the github issue tracker that can be found here > >>>>>> > >>>>>> https://github.com/SquareBracketAssociates/ > UpdatedPharoByExample/issues > >>>>>> > >>>>>> I will try to fix any problem reported but if I cannot , the fix > will have to move to version 6 > >>>>>> > >>>>>> As always thanks to all people contributing into the impossible > .... making Pharo more amazing > >>>>>> > >>>>>> If you want to contribute feel free to do so with a pull request. > >>>>>> > >>>>>> Does not matter if you are beginner because even minor corrections > like correcting mistakes in the grammar or content of the text, updated > pictures, or just a few lines of extra info are more than enough and more > than welcomed. Many Pharo beginners have already done so . > >>>>>> > >>>>>> -Salute to fellow Guardians of The Light > >>>>> > >>>>> > >>>>> I found some problems, but I don't have time to report/fix them now, > I 'll try to report them > >>>>> later (today or tomorrow). > >>>>> > >>>>> > >>>> > >>> > > I know fixed most text in the chapter. At least there are no notes on > tools that aren't there anymore and I cut those things that aren't true > anyone. > But I would like to do some more pass over it. > Instead of just cutting, we could add some new things. > Explaing the RB-Pattern syntax is maybe to much. But I would like to add > it. > Maybe I'll put some notes on criticbrower and QA. >

Nov. 8, 2016

Re: [Pharo-users] [UFFI] How to get a string from the a void pointer

by Dimitris Chloupis

AT LAST !!!! I DID IT!!! The problem was that I was not storing a crucial value for an instance variable , so the void pointer was wrong. Corrected and I can see now the "hello" string inside Pharo :) Now I can exchange data between C++ and Pharo and use that to call C++ functions/methods inside a C++ executable from Pharo. Unreal and Pharo can now become a reality. Huge thank you for Esteban and UFFI, awesome :D UFFI is far easier than I expected , but still I would like some more information for how to dereference pointer . On Mon, Nov 7, 2016 at 10:30 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > So I managed to port all C++ functions to pharo, which basically includes > the following > > Not full definition of function > > open() > lseek() > close() > mmap() > > I have tested them all, they all return proper values from inside Pharo > and Pharo does not crash. > > it seems also that mmap works because it returns a void pointer as it > should. This pointer points to the shared memory where I have put the > string "hello" from another C++ program that has shared the memory . > > So how can from Pharo take the void pointer > > "(void*)@ 16rFFFFFFFF" > > and retrieve the string "hello" that it points to ? > > Essentially I want to dereference the pointer > > I tried to send the message fromCString to the void pointer (ExternalData) > but it crashed Pharo. > > Another question, is it possible to cast a pointer ? (I do this with C++ > programm) > so can I cast from pharo the void pointer to a string pointer ? > > I have also no idea if the void pointer points to a proper memory address > , the documentation says that all pointers live in head but I have no way > to confirm this. > > I am so close to sharing memory between Pharo and C++ that I can smell it > :D >

Nov. 7, 2016

[UFFI] How to get a string from the a void pointer

by Dimitris Chloupis

So I managed to port all C++ functions to pharo, which basically includes the following Not full definition of function open() lseek() close() mmap() I have tested them all, they all return proper values from inside Pharo and Pharo does not crash. it seems also that mmap works because it returns a void pointer as it should. This pointer points to the shared memory where I have put the string "hello" from another C++ program that has shared the memory . So how can from Pharo take the void pointer "(void*)@ 16rFFFFFFFF" and retrieve the string "hello" that it points to ? Essentially I want to dereference the pointer I tried to send the message fromCString to the void pointer (ExternalData) but it crashed Pharo. Another question, is it possible to cast a pointer ? (I do this with C++ programm) so can I cast from pharo the void pointer to a string pointer ? I have also no idea if the void pointer points to a proper memory address , the documentation says that all pointers live in head but I have no way to confirm this. I am so close to sharing memory between Pharo and C++ that I can smell it :D

Nov. 7, 2016

Re: [Pharo-users] Pharo desktop UI

by vikenti

Ok, i understand. The Spec famework is under development so it changes frequently. Regarding my problem - thanks to Denis Kudriashov - the solution is simple: initializeWidgets ... locationField := LocationFieldMorph new asSpecAdapter. "adding these two lines below forces morph to occupy all layout cell" locationField morph vResizing: #spaceFill. locationField morph hResizing: #spaceFill. ... On Mon, 7 Nov 2016 06:26:41 -0800 (PST) "jfabry [via Smalltalk]" <ml-node+s1294792n4922070h35(a)n4.nabble.com> wrote: > > > I understand what you are asking, in previous versions of the documentation we had something like this. However this turned out to be a bad idea since this is too closely linked to the actual implementation. Making internal changes to the Spec interpreter means that this documentation also needs to be updated. We donât have the resources for that, sadly this documentation became out of date and simply wrong so we had to remove it. > > So for what you are asking the code is the only reference, sorry. > > -- > Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > > > On 06 Nov 2016, at 18:23, vikenti <vikenti.potapov(a)gmail.com> wrote: > > > > Maybe you can give some brief explanaition how to create Spec-compatible custom UI control? (Like TextModel or ButtonModel, etc.) How to create model class, corresponding adapter and how to process common and custom UI events (mouse\keyboard\focus ordering\changing). > > I think such guide should also be included in Spec booklet. > > > > > > _______________________________________________ > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/Pharo-desktop-UI-tp4921212p4922070.html > > To unsubscribe from Pharo desktop UI, visit http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no… -- Ð¡ ÑÐ²Ð°Ð¶ÐµÐ½Ð¸ÐµÐ¼, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² http://vikenti.ru ÑÐµÐ».: +7 (917) 880 25 07 (Ð³. ÐÐ°Ð·Ð°Ð½Ñ) -- View this message in context: http://forum.world.st/Pharo-desktop-UI-tp4921212p4922097.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 7, 2016

Re: Speed up JPG images loading

by matteob8

Hi Sven, my test are close to yours, so there's nothing wrong with my image. [ Form fromFileNamed: 'pharo.png' ] benchFor: 10 seconds. "a BenchmarkResult(708 iterations in 10 seconds 4 milliseconds. 70.772 per second)" In case, I'll follow your hint to resort to Fuel. BTW I'm using Pharo5.0, Latest update: #50761, on a Linux machine Thanks, Matteo -- View this message in context: http://forum.world.st/Speed-up-JPG-images-loading-tp4921772p4922093.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 7, 2016