- Pharo-dev - lists.pharo.org

Smalltalkhub issue. Some public projects not allow commiting. 500 error

by Denis Kudriashov

Hi. I try to commit to Car/Ghost and Pharo/Rubric. But server returned 500 error. I'm not team member there. But I normally commit to Pharo50Inbox. Anybody has same problems?

Nov. 25, 2015

Re: [Pharo-dev] what is exactly flushCache?

by Marcus Denker

Hi, Which reminds me that we should fix the flushCache.. right now we do it when installing, not at at:put: in the method dictionaryâ¦ I will clean that up soon. Marcus > On 24 Nov 2015, at 15:10, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Stephane, > > the VM caches method lookups in a lookup cache from class,selector pairs to method,primitive pairs, where primitive may be null. This is called the first-level method lookup cache. The JIT VM caches message lookups in machine code, so that a particular piece of machine code exists in a state that invokes a method for a specific class very fast by embedding the class reference in a register load and the target method in a call instruction, and having the target method verify this "cache probe" (this is an "in-line cache). The JIT also caches the translation of a byte coded method to machine code, by hiding a reference to a machine code method in a byte coded method. > > These caches can be invalidated in several circumstances: > > 1a. if one adds or removes a method from a class's method dictionary it may change the correct results of a lookup not merely of the class whose dictionary was updated but also subclasses of the class. > 1b. if one replaces a method in a method dictionary this changes the target method for a lookup of the selector for the class and subclasses > > 2. if one wants to rewrite the byte code or literals of a method, for example because a Slot definition has changed, then if the method has been compiled to machine code, the machine code must be discarded before the new code may be executed > > 1a & 1b are done via Symbol>>flushCache. In response the normal VM flushes its first-level method lookup cache, and the JIT also scans all of machine code looking for inline caches with that selector, and voiding them, reverting each send site for that selector to the "unlinked" state. > > There used to be confusion in Squeak, which Pharo inherited, that using CompiledMethod>>flushCache was somehow the right way to void caches when updating method dictionaries, flushing the old method in the dictionary, if any, and the new method. It isn't, precisely because adding or removing methods affects the visibility of inherited methods with the same selector. So MethodDictionary code should use Symbol>>flushCache, and only once, on each update of a method dictionary. As a result, the VM will ensure that the necessary send caches are flushed for that selector. > > 2. is done via CompiledMethod>>flushCache. In response the VM searches the first-level method lookup cache and removes all entries whose target is the method. In addition the JIT discards the machine code for the method, and searches for all send sites with that method's machine code as the target and voids them, reverting them to the unlinked state. > > The VM must be told to flush the cached state for a compiled method via CompiledMethod>>flushCache and will /try/ and void the state for that method. But it can't always deal with existing activations of that method, because if there are activations running the machine code, that machine code can't merely be thrown away, and can't be replaced because its length may change, depending on literals or byte codes. So this kind of byte coded method manipulation needs to be done with case and some understanding of the total system state. > > HTH > > > On Tue, Nov 24, 2015 at 9:37 AM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > Clement > > do you know what is flushCache and why we need to invoke it? > > Stef > > > > > -- > _,,,^..^,,,_ > best, Eliot

Nov. 25, 2015

Delay>>waitOtherwise:

by Ben Coman

I think I made a mistake introducing Delay>>waitOtherwise: to be used by World>>interCyclePause: . Its requirement that #schedule: return a boolean complicates all those methods. In review now, I was being too conservative while letting the refactored delay scheduler code settle in. Would anyone mind if I revert that? cheers -ben

Nov. 25, 2015

[pharo-project/pharo-core] 5797da: 50467

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 5797daee77dab478fdf140d65f9a59e35af0196c https://github.com/pharo-project/pharo-core/commit/5797daee77dab478fdf140d6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-25 (Wed, 25 Nov 2015) Changed paths: M DebuggerModel.package/DebugSession.class/instance/debugging actions/terminate.st M Morphic-Base.package/DropFilesEvent.class/README.md M Morphic-Base.package/DropFilesEvent.class/instance/dispatching/sentTo_.st M Morphic-Core.package/DropEvent.class/instance/dispatching/sentTo_.st M NautilusCommon.package/AnnotationRequest.class/README.md R NautilusCommon.package/AnnotationRequest.class/instance/requests/documentation.st R NautilusCommon.package/AnnotationRequest.class/instance/requests/firstComment.st R NautilusCommon.package/AnnotationRequest.class/instance/requests/masterComment.st R NautilusCommon.package/AnnotationRequest.class/instance/requests/priorVersionsCount.st R NautilusCommon.package/AnnotationRequest.class/instance/requests/recentChangeSet.st R Reflectivity-Examples.package/BreakpointIconStyler.class/README.md R Reflectivity-Examples.package/BreakpointIconStyler.class/definition.st R Reflectivity-Examples.package/BreakpointIconStyler.class/instance/defaults/highlightColor.st R Reflectivity-Examples.package/BreakpointIconStyler.class/instance/defaults/icon.st R Reflectivity-Examples.package/BreakpointIconStyler.class/instance/defaults/iconBlock_.st R Reflectivity-Examples.package/BreakpointIconStyler.class/instance/defaults/iconLabel.st R Reflectivity-Examples.package/BreakpointIconStyler.class/instance/defaults/iconLabel_.st R Reflectivity-Examples.package/BreakpointIconStyler.class/instance/testing/shouldStyleNode_.st A Reflectivity-Tools-Tests.package/WPDummy.class/instance/as yet unclassified/exampleMessageSend.st A Reflectivity-Tools-Tests.package/WPDummy.class/instance/as yet unclassified/exampleOperation.st A Reflectivity-Tools-Tests.package/WatchpointTests.class/instance/values/testSendMessage.st M Reflectivity-Tools-Tests.package/WatchpointTests.class/instance/values/testTimestamp.st A Reflectivity-Tools.package/Break.class/README.md A Reflectivity-Tools.package/Break.class/class/break/break.st A Reflectivity-Tools.package/Break.class/definition.st A Reflectivity-Tools.package/Breakpoint.class/README.md A Reflectivity-Tools.package/Breakpoint.class/class/class initialization/initialize.st A Reflectivity-Tools.package/Breakpoint.class/class/cleanup/cleanUp.st A Reflectivity-Tools.package/Breakpoint.class/class/cleanup/removeAll.st A Reflectivity-Tools.package/Breakpoint.class/class/cleanup/removeFrom_.st A Reflectivity-Tools.package/Breakpoint.class/definition.st A Reflectivity-Tools.package/Breakpoint.class/instance/accessing/level.st A Reflectivity-Tools.package/Breakpoint.class/instance/accessing/level_.st A Reflectivity-Tools.package/Breakpoint.class/instance/accessing/link.st A Reflectivity-Tools.package/Breakpoint.class/instance/accessing/link_.st A Reflectivity-Tools.package/Breakpoint.class/instance/accessing/node.st A Reflectivity-Tools.package/Breakpoint.class/instance/accessing/node_.st A Reflectivity-Tools.package/Breakpoint.class/instance/api/always.st A Reflectivity-Tools.package/Breakpoint.class/instance/api/condition_.st A Reflectivity-Tools.package/Breakpoint.class/instance/api/once.st A Reflectivity-Tools.package/Breakpoint.class/instance/install/install.st A Reflectivity-Tools.package/Breakpoint.class/instance/install/remove.st A Reflectivity-Tools.package/Breakpoint.class/instance/links/breakLink.st A Reflectivity-Tools.package/Breakpoint.class/instance/links/breakLinkConditional.st A Reflectivity-Tools.package/Breakpoint.class/instance/links/breakLinkOneShot.st A Reflectivity-Tools.package/BreakpointIconStyler.class/README.md A Reflectivity-Tools.package/BreakpointIconStyler.class/definition.st A Reflectivity-Tools.package/BreakpointIconStyler.class/instance/defaults/highlightColor.st A Reflectivity-Tools.package/BreakpointIconStyler.class/instance/defaults/icon.st A Reflectivity-Tools.package/BreakpointIconStyler.class/instance/defaults/iconBlock_.st A Reflectivity-Tools.package/BreakpointIconStyler.class/instance/defaults/iconLabel.st A Reflectivity-Tools.package/BreakpointIconStyler.class/instance/defaults/iconLabel_.st A Reflectivity-Tools.package/BreakpointIconStyler.class/instance/testing/shouldStyleNode_.st M Reflectivity-Tools.package/Watchpoint.class/instance/install/install.st M Reflectivity-Tools.package/WatchpointIconStyler.class/instance/defaults/iconBlock_.st A Reflectivity-Tools.package/WatchpointWindow.class/README.md A Reflectivity-Tools.package/WatchpointWindow.class/class/instance creation/new.st A Reflectivity-Tools.package/WatchpointWindow.class/class/instance creation/on_.st A Reflectivity-Tools.package/WatchpointWindow.class/class/instance creation/openOn_.st A Reflectivity-Tools.package/WatchpointWindow.class/class/specs/defaultSpec.st A Reflectivity-Tools.package/WatchpointWindow.class/definition.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/accessing/defaultWindowModelClass.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/accessing/inspectIt.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/accessing/inspectIt_.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/accessing/label.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/accessing/label_.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/accessing/list.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/accessing/list_.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/accessing/watchpoint.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/accessing/watchpoint_.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/api/extent.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/api/title.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/initialization/initializePresenter.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/initialization/initializeWidgets.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/updating/refreshItems.st A Reflectivity-Tools.package/WatchpointWindow.class/instance/updating/step.st R Reflectivity.package/Break.class/README.md R Reflectivity.package/Break.class/class/break/break.st R Reflectivity.package/Break.class/definition.st R Reflectivity.package/Breakpoint.class/README.md R Reflectivity.package/Breakpoint.class/class/class initialization/initialize.st R Reflectivity.package/Breakpoint.class/class/cleanup/cleanUp.st R Reflectivity.package/Breakpoint.class/class/cleanup/removeAll.st R Reflectivity.package/Breakpoint.class/class/cleanup/removeFrom_.st R Reflectivity.package/Breakpoint.class/definition.st R Reflectivity.package/Breakpoint.class/instance/accessing/level.st R Reflectivity.package/Breakpoint.class/instance/accessing/level_.st R Reflectivity.package/Breakpoint.class/instance/accessing/link.st R Reflectivity.package/Breakpoint.class/instance/accessing/link_.st R Reflectivity.package/Breakpoint.class/instance/accessing/node.st R Reflectivity.package/Breakpoint.class/instance/accessing/node_.st R Reflectivity.package/Breakpoint.class/instance/api/always.st R Reflectivity.package/Breakpoint.class/instance/api/condition_.st R Reflectivity.package/Breakpoint.class/instance/api/once.st R Reflectivity.package/Breakpoint.class/instance/install/install.st R Reflectivity.package/Breakpoint.class/instance/install/remove.st R Reflectivity.package/Breakpoint.class/instance/links/breakLink.st R Reflectivity.package/Breakpoint.class/instance/links/breakLinkConditional.st R Reflectivity.package/Breakpoint.class/instance/links/breakLinkOneShot.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50466.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50467.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50466.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50467.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/SyntaxErrorDebugger.class/instance/initialization/release.st Log Message: ----------- 50467 17103 support for watchpoint with optionWeakAfter metalink https://pharo.fogbugz.com/f/cases/17103 17107 Strange effect after opening the Debugger: sometimes two UI processes https://pharo.fogbugz.com/f/cases/17107 17105 Have a minimal UI for seeing watchpoints https://pharo.fogbugz.com/f/cases/17105 17101 clean AnnotationRequest https://pharo.fogbugz.com/f/cases/17101 17100 DropEvent should not check the type in #sentTo: https://pharo.fogbugz.com/f/cases/17100 http://files.pharo.org/image/50/50467.zip

Nov. 25, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50467 Home: https://github.com/pharo-project/pharo-core

Nov. 25, 2015

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

by Thierry Goubier

2015-11-25 13:00 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Wed, Nov 25, 2015 at 6:31 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: > > > > .... > > > > 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. > > Thats cool. What are the other communities? > cheers -ben > > Squeak, GemStone, older Pharo versions. ST/X probably has a branch of it too (Jan Vrany). There is support for Cuis. Thierry

Nov. 25, 2015

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

by Ben Coman

On Wed, Nov 25, 2015 at 6:31 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 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. Thats cool. What are the other communities? cheers -ben

Nov. 25, 2015

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

by Franck Warlouzet

Ok I will do that, thanks. Franck From: johan(a)inceptive.be Date: Wed, 25 Nov 2015 07:46:09 +0100 To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] Seaside REST on Pharo 50 CC: seaside(a)lists.squeakfoundation.org Hi, Seaside-REST is included in Seaside since version 3.1ConfigurationOfSeasideREST 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. regardsJohan 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 > From: stephan(a)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

Re: [Pharo-dev] Redraw Ghosts/Artifacts

by Nicolai Hess

most probable 17107 <https://pharo.fogbugz.com/f/cases/17107/Strange-effect-after-opening-the-De…> Strange effect after opening the Debugger: sometimes two UI processes

Nov. 25, 2015

R: Java Future

by Lorenzo Schiavina

Perfect Dimitris! Lorenzo Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Dimitris Chloupis Inviato: mercoledÃ¬ 25 novembre 2015 11:29 A: Pharo Development List Oggetto: Re: [Pharo-dev] Java Future 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… <https://dzone.com/articles/even-if-oracle-is-losing-interest-in-java-should…> &utm_source=Spotlight&utm_medium=email&utm_campaign=java%202015-11-24

Nov. 25, 2015