- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Redraw Ghosts/Artifacts

by Denis Kudriashov

Hi. It was my mistake. And it is fixed at 17107 2015-11-25 9:28 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > I get lots of redraw ghosts/artifacts in the latest 5.0 (retina macbook > pro), does anyone else see this too ? And something is wrong with the task > bar preview too, that cannot be fixed by redrawing the world. > >

Nov. 25, 2015

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

by Thierry Goubier

2015-11-25 10:39 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr>: > > On Nov 24, 2015, at 5:37 PM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > Hi Skip, > > 2015-11-24 17:30 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr>: > >> >> It would be nice to have some less metadata in the repository (or none at >> all), especially for merging. Method and author timestamps can be gathered >> from the commit information, the âversionâ fill in the monticello.meta >> directory is not necessary too I think, since we have the commit messages >> obviously.. >> > > Well, GitFileTree has all that code: > - Monticello metadata extraction from git logs > - Filetree without Metadata > Some of the information in the meta directory is necessary (pre/post load > scripts). > > > Where are those pre/post load scripts defined? Does anyone ever use it? > You have, in that directory: - categories (defines the package tags, for example: https://github.com/ThierryGoubier/AltBrowser/blob/pharo5/Alt-Browser.packag… ) - initializers (but it's usually empty) - package (the package name: FileTree uses that) possibly 'preamble.st' 'postscript.st' 'preambleOfRemoval*' 'postscriptOfRemoval*' Good question, I can't find any of those and I can't even find the code writing that. Dale? Dependencies (used by SLICEs). What is conflict-prone with git in that repository: - version Now, removing the entire directory for a single file... You can see the diffs of a metadata-less repository if you look at the recent commits of https://github.com/ThierryGoubier/AltBrowser/commits/pharo5 > I think having a FileTree reader/writer that is not coupled to Monticello >> would be good, but maybe Iâm saying something that is not possible. >> > > No, it is possible (everything is), but a bit complex for maintenance (how > do you track changes and corrections in the FileTree code?). > > > Of course, the sky is the limit :P. Although Iâm not sure I understand > what you mean here, could you explain? > FileTree has a large set of test cases, sample repositories, CI setup, cross-platform knowledge, bug fixes coming from a large group of users (far larger than the Pharo community). Cutting ourselves from that is counter productive and looks like a case of the NIH syndrome. > Alright so this is odd.. Martin had the same behavior. Thank you for all >> your feedback, itâs very helpful. >> > > Maybe just an effect of the ordering (github gives you a list of > repositories, isn't it?) > > > Actually now that I think of it, itâs probably due to the fact that when > you request a list of something (e.g. list of commits, list of > repositories, etc.) the API gives you a paginated result. This means that > it will give you the first 25 repositories, and a link to retrieve the next > 25, and so on. Pagination still has to be implemented. API documentation > about pagination is here: https://developer.github.com/v3/#pagination > Ok, understood.

Nov. 25, 2015

Re: [Pharo-dev] Java Future

by Dimitris Chloupis

Clickbait ! ClickBAIT !!!!! Let me remind you that bloggers have been declaring Java dead for over a decade now. Java still goes strong and is the undisputed king of Enterprise coding no other language can even remotely touch it, mainly because of its huge powerful library made for big businesses. Pharo cannot compete with Java, it does not have the resources to, right now the only true competitor to java is C# and even C# though backed by Micro$oft , still it lags very much behind it in terms of popularity. Let me also remind you that Java is the language that mutilated the then undisputed king of of programming languages C++ stealing away tons of its coders. Probably the biggest migration of coders ever. Only fools underestimate Java. Java is big, Java is ugly, Java is powerful and Java is here to stay for a long, long time. My advice to Pharo, keep doing what you know best, helping lone coders and small teams compete with large companies in terms of productivity. Dont compete, innovate. On Wed, Nov 25, 2015 at 12:03 PM S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > *Opportunities.. for Pharo..* > > > *The email, sent to InfoWorld on Tuesday by a former high-ranking Java > official, claimed to feature details from inside Oracle. It said the > company was becoming a cloud company, competing with Salesforce, and âJava > has no interest to them anymore.â The subject line cited âJava â planned > obsolescence.â* > > *Oracle is not interested in empowering its competitors and doesnât want > to share innovation, the email further alleges. The company is slimming > down Java EE (Enterprise Edition), but it also doesnât want anyone else to > work on Java or Java EE and is sidelining the JCP (Java Community Process). > âThey have a winner-take-all mentality and they are not interested in > collaborating,â said the email. âProprietary product work will be done on > WebLogic, and thereâll be a proprietary microservices platform.â WebLogic > is the Java application server Oracle acquired when it bought BEA Systems > in 2008.* > > > https://dzone.com/articles/even-if-oracle-is-losing-interest-in-java-should… >

Nov. 25, 2015

Java Future

by S Krish

*Opportunities.. for Pharo..* *The email, sent to InfoWorld on Tuesday by a former high-ranking Java official, claimed to feature details from inside Oracle. It said the company was becoming a cloud company, competing with Salesforce, and âJava has no interest to them anymore.â The subject line cited âJava â planned obsolescence.â* *Oracle is not interested in empowering its competitors and doesnât want to share innovation, the email further alleges. The company is slimming down Java EE (Enterprise Edition), but it also doesnât want anyone else to work on Java or Java EE and is sidelining the JCP (Java Community Process). âThey have a winner-take-all mentality and they are not interested in collaborating,â said the email. âProprietary product work will be done on WebLogic, and thereâll be a proprietary microservices platform.â WebLogic is the Java application server Oracle acquired when it bought BEA Systems in 2008.* https://dzone.com/articles/even-if-oracle-is-losing-interest-in-java-should…

Nov. 25, 2015

Re: [Pharo-dev] News about FastTable

by Ferlicot D. Cyril

Le 24/11/2015 18:47, Thierry Goubier a Ã©crit : > Hi Cyril, > > Agreed. > > Selection probably doesn't work very well: I got a DNU in > updateSelectionWithCollectBlock: > > (running exampleTree1, and trying the select in subtree then collapse) > > In Morphic-Widgets-FastTable-CyrilFerlicot.133 > > (changing collectAsSet: by collect: gives the correct behavior on the > selection). > > Thierry > It should work now. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Nov. 25, 2015

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

by Skip Lentz

> On Nov 24, 2015, at 5:37 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Skip, > > 2015-11-24 17:30 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr <mailto:skip.lentz@inria.fr>>: > > It would be nice to have some less metadata in the repository (or none at all), especially for merging. Method and author timestamps can be gathered from the commit information, the âversionâ fill in the monticello.meta directory is not necessary too I think, since we have the commit messages obviously.. > > Well, GitFileTree has all that code: > - Monticello metadata extraction from git logs > - Filetree without Metadata > Some of the information in the meta directory is necessary (pre/post load scripts). Where are those pre/post load scripts defined? Does anyone ever use it? > I think having a FileTree reader/writer that is not coupled to Monticello would be good, but maybe Iâm saying something that is not possible. > > No, it is possible (everything is), but a bit complex for maintenance (how do you track changes and corrections in the FileTree code?). Of course, the sky is the limit :P. Although Iâm not sure I understand what you mean here, could you explain? > Alright so this is odd.. Martin had the same behavior. Thank you for all your feedback, itâs very helpful. > > Maybe just an effect of the ordering (github gives you a list of repositories, isn't it?) Actually now that I think of it, itâs probably due to the fact that when you request a list of something (e.g. list of commits, list of repositories, etc.) the API gives you a paginated result. This means that it will give you the first 25 repositories, and a link to retrieve the next 25, and so on. Pagination still has to be implemented. API documentation about pagination is here: https://developer.github.com/v3/#pagination

Nov. 25, 2015

Re: [Pharo-dev] Debugging a failing test doesn't include the full stack

by Guillermo Polito

Iâve seen this problem tons of times since Pharo4. But the worst is that I never found a way to reproduce it. To me there is some side effect somewhere. Because it does not happen in a fresh image, but once you have it, you have it all the time. > On 24 nov 2015, at 1:49 p.m., Ben Coman <btc(a)openinworld.com> wrote: > > > > On Tue, Nov 24, 2015 at 7:32 AM, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: > I'm trying to debug a failing test case in Pharo 5, but for some reason in certain tests I can't see the full stack, so basically I can't fix nor diagnose the failing test within the debugger because I only get the assert notification. > > > > This doesn't happen in Pharo 4, there seems to be a refactoring of the TestCase hierarchy, but I don't know how it affects the exception handling, which in the case of Glorp seems to not be very orthodox. > > Regards! > â > > Esteban A. Maringolo > > Possible workaround hack is to remove some of the conditions > from #on:do: so you get a debugger straight away on the original error > rather than storing it for later. > > TestResult>>runCase: aTestCase > [ > aTestCase announce: TestCaseStarted withResult: self. > aTestCase runCase. > aTestCase announce: TestCaseEnded withResult: self. > self addPass: aTestCase] > on: self class failure , self class skip, self class warning, self class error > do: [:ex | ex sunitAnnounce: aTestCase toResult: self] > > cheers -ben

Nov. 25, 2015

Re: [Pharo-dev] Merge tests and mocks of Monticello

by Guillermo Polito

I remember that Monticello tests make dirty and load/unload the mocks package. Thatâs why itâs separated. > On 24 nov 2015, at 11:11 p.m., Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > > see that a Test need a method in an extension, that must be for > that reason that there is two packages.

Nov. 25, 2015

Redraw Ghosts/Artifacts

by Sven Van Caekenberghe

I get lots of redraw ghosts/artifacts in the latest 5.0 (retina macbook pro), does anyone else see this too ? And something is wrong with the task bar preview too, that cannot be fixed by redrawing the world.

Nov. 25, 2015

Re: [Pharo-dev] Seaside REST on Pharo 50

by Johan Brichau

Hi, Seaside-REST is included in Seaside since version 3.1 ConfigurationOfSeasideREST is outdated; it works with version 3.0 Therefore, load the âRESTâ group from ConfigurationOfSeaside3: Metacello new configuration: 'Seaside3'; version: #stable; load: âREST' If you want to experiment with all of Seaside, load everything: Metacello new configuration: 'Seaside3'; version: #stable; load: âOneClick' Seaside is also not tested on Pharo5 as itâs still a moving target. Use Pharo4 if you want to make sure it works. regards Johan > On 25 Nov 2015, at 01:07, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: > > I was using both ConfigurationOfSeaside3 and ConfigurationOfSeasideRest. Is it the wrong way ? > > Franck > > > To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > > From: stephan(a)stack.nl <mailto:stephan@stack.nl> > > Date: Wed, 25 Nov 2015 00:26:05 +0100 > > Subject: Re: [Pharo-dev] Seaside REST on Pharo 50 > > > > On 24/11/15 16:43, Franck Warlouzet wrote: > > > We are working on Pharo 50, and we noticed that Seaside-REST is not > > > working anymore. > > > > How are you loading it? > > > > (ConfigurationOfSeaside3 project version: #'release3.2') load: > > #('OneClick' 'REST') > > > > There could be a configuration problem, or not the right combination of > > groups. > > > > To resolve it, compare the package cache from Pharo4 vs Pharo5 after > > loading. > > > > Stephan > > > >

Nov. 25, 2015