May 2015 - Pharo-dev - lists.pharo.org

[ANN] Garage 0.2 - GarageGlorp - GarageConnectionPool

by Guillermo Polito

Hi all, little announcement here. Updated Glorp v1.11 ================ I updated/merged latest configurations of Glorp with latest changes fixing TimeStamps and similar. I have fully green test cases in Pharo 5. Latest version of the configuration is in Glorp's repository and copied to the corresponding MetaRepos. GarageGlorp v0.1 ============= A Garage extension to connect it to Glorp. All Glorp tests are green in Pharo3 and Pharo4. https://ci.inria.fr/dbxtalk/view/Garage-Glorp/ http://guillep.github.io/DBXTalk/glorp.html Garage 0.2 ======== Some patches on Garage 0.1 were required to make garage glorp work. - rows should be more polymorphic with arrays - added isResultSet telling if the result of a query has rows Garage Connection Pool v0.1 ====================== A connection pool package featuring - control of idle connections - control of maximum connections to create http://guillep.github.io/DBXTalk/garage/connection_pooling.html Cheers, Guille

May 18, 2015

Re: [Pharo-dev] Default package comment

by Christophe Demarey

Le 15 mai 2015 Ã 22:39, Sergio Fedi a Ã©crit : > > Personally, I do not fear to change the comment implementation later. > That's what Smalltalk is good at. +1. But the most difficult thing is not to change the implementation but all its usage. if people start to use a feature and you change the way to use it after, it is more difficult to update all users of the feature. > But that doesn't mean it's the right choice :) > > The thing is that we can go full speed with this and make comments for: > > oneLineSummary > longDescription > usageDescription ok > preInstallComment > postInstallComment what is that? if it is Smalltalk code to run before/after the installation, it should not be in the comment but in a separated method. Pharo misses a package setUp and tearDown methods. > authorshipText > contactDescription > creationDate > lastUpdateDate This information is meta-information on a package and should not be lost in the package comment. > and a long etcetera > > Or we could go beyond this and define set of properties, each one with it's priority to be shown and some way to define the order of rendering. > > Problem is: where to draw the line? > > My initial strategy was to have comments and then model the commonalities of all package comments away to the appropiate method/variable/data I already started to work on some specific package meta-data. As I wrote before, for now, I store it in the PackageManifest because Monticello does not have a good support for meta-data. But anyway, we could just see that as an "implementation details". What I think is important is not to work directly with the PackageManifest but having an object manipulating it and able to answer to selectors like: MyPackage>>description MyPackage>>description: aText ... MyPackage>>aMetadata MyPackage>>aMetadata: value I work on a spec widget to edit some package meta-data. Maybe you could do the same to be able to present other meta-data than the package comment from Nautilus. It is more work and can just come for a second version. Regards, Christophe

May 18, 2015

[pharo-project/pharo-core]

by GitHub

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

May 18, 2015

[pharo-project/pharo-core] a35c2a: 50048

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a35c2ad504e4a66c8ce7f6f7a0af5f9c428c19f5 https://github.com/pharo-project/pharo-core/commit/a35c2ad504e4a66c8ce7f6f7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-18 (Mon, 18 May 2015) Changed paths: M DebuggerModel.package/DebugContext.class/instance/private/confirmOnTraitOverwrite_inClass_.st R FileSystem-Zip.package/ZipFileSystemDirectory.class/instance/creation/ensureCreateDirectory_.st M Graphics-Files.package/ImageReadWriter.class/class/image reading%2Fwriting/formFromStream_.st A Graphics-Files.package/ImageReadWriter.class/class/image reading%2Fwriting/readerClassFromStream_.st R Kernel.package/DelayNullScheduler.class/instance/timer process/schedulingProcess.st R Morphic-Base.package/UpdatingMenuItemMorph.class/instance/private/balloonText_.st M Refactoring-Critics.package/RBFutureDeprecationWarningRule.class/instance/private/oldSelectors.st M Refactoring-Critics.package/RBFutureDeprecationWarningRule.class/instance/running/checkMethod_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50047.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50048.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50047.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50048.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R UIManager.package/StartupUIManager.class/instance/private/deactivate.st Log Message: ----------- 50048 15551 debugger does not accept code change https://pharo.fogbugz.com/f/cases/15551 15548 core image: remove methods that are equivalent to ones they override https://pharo.fogbugz.com/f/cases/15548 15547 RBFutureDeprecationWarningRule not highlighting the issue https://pharo.fogbugz.com/f/cases/15547 15539 JPEGReadWriter class>>understandsImageFormat: result unexpected https://pharo.fogbugz.com/f/cases/15539 http://files.pharo.org/image/50/50048.zip

May 18, 2015

Re: [Pharo-dev] Please integrate 15523 and 15468

by stepharo

Le 18/5/15 02:44, Sean P. DeNigris a Ã©crit : > If there is no objection, please integrate: > > Issue 15523: Code Cruft Rule Only Matches One-Liners > https://pharo.fogbugz.com/default.asp?15523 Sean I did not integrate it because it changes the package of the halt methods. I think that it would be good to have a package with all the Halt and methods, because we do not need to have them all in kernel. Stef > > Issue 15468: Enhance the Welcome window > https://pharo.fogbugz.com/default.asp?15468 > > Especially the second one, which was aimed at supporting our new users for > the 4.0 release. > > Thanks! > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Please-integrate-15523-and-15468-tp4826949.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

May 18, 2015

Re: [Pharo-dev] Project set up

by valmy roi

I'm not an expert in script writing. I think this is a feature that should be added to pharo. That is, when you finish writing your your project, it creates a launcher for it. Vous pouvez m'aider, M. Stephane? Le 18 mai 2015 07:44, "stepharo" <stepharo(a)free.fr> a Ã©crit : > for now you can give a script that loads the project. > This is how the configuration browser (check inside the tools menu) works. > In the future we will have a binary version. > > stef > > Le 17/5/15 16:55, valmy roi a Ã©crit : > >> Hi, >> Is there a way to export a project from pharo? I explain: create a set >> up of a project (game for example) so that i can give it to someone >> to play, and he will not need to import it in pharo. >> If it doesn't exist, it should de created >> >> > >

May 18, 2015

Re: [Pharo-dev] empty package "'a MCWorkingCopy(ConfigurationOfRubric)'"

by stepharo

Yes I saw that and I have a lot of problem to find a package when I want to add a repo to a new package. Le 13/5/15 21:10, Nicolai Hess a Ã©crit : > Pharo 50046 contains a strange package: > > 'a MCWorkingCopy(ConfigurationOfRubric)' > >

May 18, 2015

Re: [Pharo-dev] Project set up

by stepharo

for now you can give a script that loads the project. This is how the configuration browser (check inside the tools menu) works. In the future we will have a binary version. stef Le 17/5/15 16:55, valmy roi a Ã©crit : > Hi, > Is there a way to export a project from pharo? I explain: create a set > up of a project (game for example) so that i can give it to someone > to play, and he will not need to import it in pharo. > If it doesn't exist, it should de created >

May 18, 2015

WhatsUp from: 2015-05-18 until: 2015-05-31

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2015-05-31 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

May 18, 2015

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

and the gods, right on time, have smitten me down. The Slang changes have broken the VM, so I've taken the VMs down. On Sun, May 17, 2015 at 8:23 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > ...at http://www.mirandabanda.org/files/Cog/VM/VM.r3349. > > I hope that the Squeak VMs here-in are final Spur 5.0 and Squeak 4.6 VMs. > The last known serious bug in Spur has been found and fixed with these > VMs. Of course uch hubris is asking for it. I await the wrath of the gods. > > CogVM binaries as per VMMaker.oscog-eem.1313/r3349 > > General: > Make the bounds check in primitiveObject:perform:... > more restrictive and fix bugs in the commentary. > > Make stack pages a reasonable size. My math was > wrong and the size was half as big as intended. > > Extend the fastPrimTrace scheme to trace stack overflow, prim failure and > prim > retry to help debug the phantom stack frame bug in Cog Spur. > > Fix old bug in ceMNUFromPICMNUMethod:receiver: that has been masked by > cacheing of MNU method in MNU PIC entries. ceMNUFromPICMNUMethod:receiver: > must set up lkupClass before calling handleMNU:... > > Spur: > Fix ceActivateFailingPrimitiveMethod: to return properly after retrying > a primitive after checkForAndFollowForwardedPrimitiveState. e.g. fixes > | s | 1 to: 5 do: [:i| s := 'bar'. s becomeForward: 'bzzt' copy. 'foo' > <= s] > > Fix bug in followForwardedFrameContents:stackPointer: so that arguments are > actually followed. N.B. drives the above bug underground ;-). > so that named constants (defines) are not elided. > > Make accessor depth calculation more accurate by not considering > fetchInteger:ofObject: and arraySize: et al as object accessors. > > Make the read-before-written initializer safer, only initialzing simple > types. > > Newspeak: > Remove landmine left from restructing implicit receiver and outer sends as > clean sends. > > Plugins: > Regenerated because of changes in accessorDepth calculation, > constant elimination, and read-before-use initialization. > -- > best, > Eliot > -- best, Eliot

May 18, 2015