November 2016 - Pharo-users

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

Re: [Pharo-users] About balkanisation

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 07/11/16 02:50, Esteban Lorenzano wrote: [...] > What I mean is that we can help any transition, but at the end there is no way of having a ânice, coexistingâ ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose oneâ¦ right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticelloâ¦ and that way of doing has a limit. A limit I think we already passed. [...] That's clarifying. Thanks a lot Esteban. I will try to keep myself on the Monticello boat a little longer, until the filetree and Iceberg stuff become clearer to me and I can see how to use them in a way that doesn't interrupt the workflow I have now (as happens with Monticello and Fossil). > Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :) Yes, Dale, your experience would be very appreciated. Cheers, Offray

Nov. 7, 2016

Iceberg/GitFileTree (was Re: about balkanisation)

by Thierry Goubier

Nicolas, I changed the subject, it seems appropriate. 2016-11-07 16:56 GMT+01:00 Nicolas Passerini <npasserini(a)gmail.com>: > > 2016-11-07 16:26 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >>> The problem I found is that in order to recreate sequential numbers, you >>> have to load all commits into the image. >>> >> >> Why? GitFileTree doesn't need to do that at all! Well, you know the code: >> it just ask git log to rebuild the parent / child relations for a package >> directory, and that is all... Then, like a mcz, the package isn't loaded >> into the image unless you select it in the GUI. So why did you need to load >> all the commits? >> >> Well, at the beginning, I was trying to read all the filetree metadata >> stored in the repository to build the versions as if it was mczs... and >> that was a really bad idea (slow parser for version files, hundred of files >> to scan, many files were even unreadable/broken by conflicts leftovers in >> the filetree repository). >> > > Yes you are right, I expressed myself badly. You don't have to load "the > commits". > But, you still have to create an MCVersionInfo for each version of the > package in the repository. > What you're saying is that you are using the same trick as GitFileTree does, but you have performance issues, which means... we're not talking about exactly the same thing :) (and trust me, my development machine is on the "very" slow end for the Pharo community, so I'm sensitive to performance issues). > > In fact... you can create them, it will not kill you, but I think that > this structure is not so useful, because it is always faster to use > log/revwalk to ask about the relationship between two versions/commits. > Agreed. But you will allways create some sort of MCVersionInfo / MCAncestry to be able to represent the start of this inside your system... Subtypes of MCVersionInfo do work fine there. Just have a nice, correct API call that allow you to compare two versions. (Little trick used in GitFileTree: all ancestry based on a specific commitID is shared among all the versions with it as an ancestor, in memory). Weak version info will take care of cleaning the unneeded stuff anyway. > > Moreover, we do not want to think about packages too much, we prefer to > think in terms of a whole project, so the most interesting concept for us > is the commit and not the version. Therefore, when I build a history > (sometimes I do) I create a graph of commits and not a graph of versions. > As long as you don't track commits for which the package has no version, then that seems perfectly fine. > > Finally, this leads to that, even in the case you want to load a specific > version of a specific pacakge (which is not the normal case for Iceberg), > you would specify a commitish (+ a package name) and not a version name. > I never specify a commitish, I use the GUI or Metacello (and since I'm using baselines, Metacello doesn't uses version numbers except to compare with what is inside the image). GitFileTree only uses commitish to load a version... it just happens to be able to also convert version numbers to a commitish if it is presented with a version number. The attention to version numbering is a thing of people using too much ConfigurationOf, and those people are living in the past. Thierry

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Nicolas Passerini

2016-11-07 16:26 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> The problem I found is that in order to recreate sequential numbers, you >> have to load all commits into the image. >> > > Why? GitFileTree doesn't need to do that at all! Well, you know the code: > it just ask git log to rebuild the parent / child relations for a package > directory, and that is all... Then, like a mcz, the package isn't loaded > into the image unless you select it in the GUI. So why did you need to load > all the commits? > > Well, at the beginning, I was trying to read all the filetree metadata > stored in the repository to build the versions as if it was mczs... and > that was a really bad idea (slow parser for version files, hundred of files > to scan, many files were even unreadable/broken by conflicts leftovers in > the filetree repository). > Yes you are right, I expressed myself badly. You don't have to load "the commits". But, you still have to create an MCVersionInfo for each version of the package in the repository. In fact... you can create them, it will not kill you, but I think that this structure is not so useful, because it is always faster to use log/revwalk to ask about the relationship between two versions/commits. Moreover, we do not want to think about packages too much, we prefer to think in terms of a whole project, so the most interesting concept for us is the commit and not the version. Therefore, when I build a history (sometimes I do) I create a graph of commits and not a graph of versions. Finally, this leads to that, even in the case you want to load a specific version of a specific pacakge (which is not the normal case for Iceberg), you would specify a commitish (+ a package name) and not a version name.

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Thierry Goubier

2016-11-07 16:13 GMT+01:00 Nicolas Passerini <npasserini(a)gmail.com>: > > I started creating version names using the unix date (the number of > seconds since 1970), which allows me to provide version numbers without > complex calculations and without breaking Monticello. > > Numbers are not nice but we do not use them any way, it is just to comply > with Monticello requirements. > There is a human effect to them (I like to see the numbers increasing as I add new versions, of course!) but, well, since Dale said working with .1 would work, so it is :) Git short commit ID are only convenient for long-time git experts. > >> >>> 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. >>> >> >> Yes, this is performance sensitive code. I spent a significant amount of >> time trying to optimize the smalltalk part of that in gitfiletree a few >> years ago... before I was shown that it could only scale to ~ 1000 commits >> (with a repository that had more than 8000 different versions for a >> package). >> >> Delegating everything to `git log` solved the issue. No code duplication! >> >> Overall, this is something that has worried me since the beginning of >> libgit. Libgit is low level and pushes some of the processing into Pharo, >> which is not the best tool to do high-speed processing of tree structures. >> And then, instead of designing the best solution to our problem, you end up >> trying to get the best design that doesn't hit a performance issue... >> > > I am using git log extensively, turns out to be a very powerful tool. > Libgit provides a very similar tool called revwalk ( > https://libgit2.github.com/libgit2/#HEAD/group/revwalk) So in each case > Pharo does not have to do those performance sensitive computing. > Yes! Problem solved. > > The problem I found is that in order to recreate sequential numbers, you > have to load all commits into the image. > Why? GitFileTree doesn't need to do that at all! Well, you know the code: it just ask git log to rebuild the parent / child relations for a package directory, and that is all... Then, like a mcz, the package isn't loaded into the image unless you select it in the GUI. So why did you need to load all the commits? Well, at the beginning, I was trying to read all the filetree metadata stored in the repository to build the versions as if it was mczs... and that was a really bad idea (slow parser for version files, hundred of files to scan, many files were even unreadable/broken by conflicts leftovers in the filetree repository). Thierry

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Nicolas Passerini

2016-11-07 15:59 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > 2016-11-07 15:42 GMT+01:00 Nicolas Passerini <npasserini(a)gmail.com>: > >> >> 2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goubier(a)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. >> > > I have an idea where such comparisons are done. I'd simply start by > changing version numbers to the short commit ID, and see where it breaks ... > I started creating version names using the unix date (the number of seconds since 1970), which allows me to provide version numbers without complex calculations and without breaking Monticello. Numbers are not nice but we do not use them any way, it is just to comply with Monticello requirements. > >> 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. >> > > Yes, this is performance sensitive code. I spent a significant amount of > time trying to optimize the smalltalk part of that in gitfiletree a few > years ago... before I was shown that it could only scale to ~ 1000 commits > (with a repository that had more than 8000 different versions for a > package). > > Delegating everything to `git log` solved the issue. No code duplication! > > Overall, this is something that has worried me since the beginning of > libgit. Libgit is low level and pushes some of the processing into Pharo, > which is not the best tool to do high-speed processing of tree structures. > And then, instead of designing the best solution to our problem, you end up > trying to get the best design that doesn't hit a performance issue... > I am using git log extensively, turns out to be a very powerful tool. Libgit provides a very similar tool called revwalk ( https://libgit2.github.com/libgit2/#HEAD/group/revwalk) So in each case Pharo does not have to do those performance sensitive computing. The problem I found is that in order to recreate sequential numbers, you have to load all commits into the image.

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Thierry Goubier

2016-11-07 15:42 GMT+01:00 Nicolas Passerini <npasserini(a)gmail.com>: > > 2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goubier(a)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. > I have an idea where such comparisons are done. I'd simply start by changing version numbers to the short commit ID, and see where it breaks ... > 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. > Yes, this is performance sensitive code. I spent a significant amount of time trying to optimize the smalltalk part of that in gitfiletree a few years ago... before I was shown that it could only scale to ~ 1000 commits (with a repository that had more than 8000 different versions for a package). Delegating everything to `git log` solved the issue. No code duplication! Overall, this is something that has worried me since the beginning of libgit. Libgit is low level and pushes some of the processing into Pharo, which is not the best tool to do high-speed processing of tree structures. And then, instead of designing the best solution to our problem, you end up trying to get the best design that doesn't hit a performance issue... Thierry

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Nicolas Passerini

2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goubier(a)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.

Nov. 7, 2016

Re: [Pharo-users] Pharo desktop UI

by Johan Fabry

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.

Nov. 7, 2016