Re: [Pharo-dev] Gettext broken in Pharo 3.0
Hi Usman, I committed a new version that fixes a number of things. More is needed because I notice the exporter is not detecting the domain-categories mapping anymore. Johan On 28 Feb 2014, at 15:36, Usman Bhatti usman.bha...@gmail.com wrote: Hello, I encountered a problem when trying to export the Gettext file in Pharo 3.0. In a Pharo 3.0 image, load Gettext and then do the following: TextDomainManager registerCategoryPrefix: 'Fuel' domain: 'Fuel'. GetTextExporter exportTemplate. Apparently, there are some deprecations and doing proceed on them shows a DNU: RBMethodNode does not understand isMessageNode I can report the bug somewhere to later find some time to correct it but Pharo bug tracker might not be the right place. Any ideas where this bug should be reported? If someone knowledgeable about RB related stuff can have a look at it, it would be great. tx, usman
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30783 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] b21ba3: 30783
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: b21ba344c15fd68581615d7dad98990545c32f89 https://github.com/pharo-project/pharo-core/commit/b21ba344c15fd68581615d7dad98990545c32f89 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-03-01 (Sat, 01 Mar 2014) Changed paths: A Keymapping-KeyCombinations.package/KMAltModifier.class/instance/accessing/eventCode.st A Keymapping-KeyCombinations.package/KMCommandModifier.class/instance/accessing/eventCode.st A Keymapping-KeyCombinations.package/KMCtrlModifier.class/instance/accessing/eventCode.st A Keymapping-KeyCombinations.package/KMShiftModifier.class/instance/accessing/eventCode.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testAsString.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testBadComposedCmdShortcutFails.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testChainIntegerSucceds.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testChainShortcutSucceds.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testChainSimpleCharsSucceds.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testCmdIntegerSucceds.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testCmdKeySucceds.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testCmdShiftSucceds.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testComplexChainMatches.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testCreation.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testModifiedShortcutsMatch.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testShiftKeySucceds.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testSimpleChainMatches.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testSingleShortcutsMatch.st R Keymapping-Tests.package/KMShortcutTest.class/instance/as yet unclassified/testTripleChainShortcutSucceds.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testAsString.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testBadComposedCmdShortcutFails.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testChainIntegerSucceds.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testChainShortcutSucceds.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testChainSimpleCharsSucceds.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testCmdIntegerSucceds.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testCmdKeySucceds.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testCmdShiftSucceds.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testComplexChainMatches.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testCreation.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testEventCodes.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testModifiedShortcutsMatch.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testShiftKeySucceds.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testSimpleChainMatches.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testSingleShortcutsMatch.st A Keymapping-Tests.package/KMShortcutTest.class/instance/tests/testTripleChainShortcutSucceds.st M Monticello.package/MCDefinition.class/class/instance creation/instanceLike_.st M Monticello.package/MCDefinition.class/definition.st M Morphic-Base.package/SystemWindow.class/class/top window/sendTopWindowToBack.st M PackageInfo.package/PackageOrganizer.class/README.md A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script436.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30783.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-MorphicAdapters.package/MorphicTreeAdapter.class/instance/widget API/menu_shifted_.st M Spec-Tools.package/MessageBrowser.class/class/specs/testSpec.st Log Message: --- 30783 12997 Class comment missing for package PackageInfo https://pharo.fogbugz.com/f/cases/12997 12952 Context menu for dependentProjcts gives DNU for a new project https://pharo.fogbugz.com/f/cases/12952 13001 SystemWindow sendTopWindowToBack does not work when invoked from World menu or global shortcut https://pharo.fogbugz.com/f/cases/13001 12957
Re: [Pharo-dev] Gettext broken in Pharo 3.0
On 01 Mar 2014, at 09:57, Johan Brichau jo...@inceptive.be wrote: More is needed because I notice the exporter is not detecting the domain-categories mapping anymore. On second view, it seems the Seaside package for gettext is not compatible anymore with changes in recent history. So, gettext on its own should be good to go now. Let me know, since I am now mostly focusing on the seaside extension that uses it cheers Johan
[Pharo-dev] [pharo-project/pharo-core] 0451c3: 30784
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 0451c3c76fa62237492df765ce289a8b6d94ad2f https://github.com/pharo-project/pharo-core/commit/0451c3c76fa62237492df765ce289a8b6d94ad2f Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-03-01 (Sat, 01 Mar 2014) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script437.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30784.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Versionner-Core-DependenciesModel.package/ConfigurationNotFound.class/README.md A Versionner-Core-DependenciesModel.package/ConfigurationNotFound.class/definition.st M Versionner-Core-DependenciesModel.package/MCModel2MTModelVisitor.class/instance/visiting/visitMCProjectAsRequiredProject_.st M Versionner-Core-DependenciesModel.package/MTDependantProject.class/instance/comparing/=.st R Versionner-Core-DependenciesModel.package/MTDependantProject.class/instance/editing/editRepositories.st A Versionner-Core-DependenciesModel.package/MTDevelopmentWorkfow.class/instance/private/isDevelopmentUsedInRelease.st M Versionner-Core-DependenciesModel.package/MTModelComparator.class/instance/comparing/is_equalsTo_.st M Versionner-Core-DependenciesModel.package/VersionnerToolBox.class/instance/spec creation/projectSpecFromRequiredProject_.st M Versionner-Spec-Browser.package/VersionnerProjectBrowser.class/instance/actions/updateRepository.st M Versionner-Spec-Browser.package/VersionnerProjectPackagesPanel.class/class/spec/defaultSpec.st M Versionner-Spec-Browser.package/VersionnerProjectPackagesPanel.class/definition.st M Versionner-Spec-Browser.package/VersionnerProjectPackagesPanel.class/instance/actions/editSelectedPackageRequirements.st M Versionner-Spec-Browser.package/VersionnerProjectPackagesPanel.class/instance/initialization/initializePresenter.st M Versionner-Spec-Browser.package/VersionnerProjectPackagesPanel.class/instance/initialization/initializeWidgets.st A Versionner-Spec-Browser.package/VersionnerProjectPackagesPanel.class/instance/selection/packageBoundToSelection.st A Versionner-Spec-Browser.package/VersionnerProjectPackagesPanel.class/instance/testing/isPackage_.st M Versionner-Spec-Browser.package/VersionnerProjectPanel.class/instance/accessing-ui/requiredProjectMenu_.st M Versionner-Spec-Browser.package/VersionnerProjectPanel.class/instance/actions/editSelectedProjectLoads.st M Versionner-Spec-Browser.package/VersionnerProjectPanel.class/instance/actions/remove_fromGroup_.st M Versionner-Spec-Browser.package/VersionnerProjectPanel.class/instance/initialization/initializePresenter.st A Versionner-Spec-Browser.package/VersionnerProjectPanel.class/instance/selection/projectBoundToSelection.st A Versionner-Spec-Browser.package/VersionnerProjectPanel.class/instance/testing/isProject_.st R Versionner-Spec-Browser.package/VersionnerProjectToolBar.class/instance/actions/releaseDevelopment.st M Versionner-Spec-Browser.package/VersionnerProjectToolBar.class/instance/initialization/initializePresenter.st A Versionner-Spec-Browser.package/extension/MTDependantProject/instance/editRepositories.st A Versionner-Spec-Browser.package/extension/MTDependantProject/instance/editVersion.st A Versionner-Spec-Browser.package/extension/TreeModel/instance/whenSelectedNodesChanged_.st M Versionner-Tests-Core-DependenciesModel.package/MTModelComparatorTest.class/instance/tests/testIsEqualsTo.st M Versionner-Tests-Core-Model.package/MBPackageInfoTest.class/instance/tests/testIsDirty.st A Versionner-Tests-Resources.package/ConfigurationOfVersionnerTestXMLParserTemplate.class/instance/baselines/baseline20_.st Log Message: --- 30784 12983 integrate Versionner 2.5 https://pharo.fogbugz.com/f/cases/12983 http://files.pharo.org/image/30/30784.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30784 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] Gettext broken in Pharo 3.0
Hi Johan, On Sat, Mar 1, 2014 at 10:47 AM, Johan Brichau jo...@inceptive.be wrote: On 01 Mar 2014, at 09:57, Johan Brichau jo...@inceptive.be wrote: More is needed because I notice the exporter is not detecting the domain-categories mapping anymore. On second view, it seems the Seaside package for gettext is not compatible anymore with changes in recent history. So, gettext on its own should be good to go now. Let me know, since I am now mostly focusing on the seaside extension that uses it For me, it is working now and the problem seems to be fixed. I have a desktop app so I am not using it with Seaside and everything seems to be working normally. tx a lot, Usman cheers Johan
[Pharo-dev] Phratch one-click
Dears, Phratch has now a portable version: https://ci.inria.fr/pharo-contribution/view/Phratch/job/Phratch-OneClick/ Thanks to JB Arnaud, the Jenkins is configured to take the latest one-click Pharo for each platform and install all the necessary (Plugins, png...). Now, no need to install anything: just download the zip file for your platform, unzip it and run Phratch. Enjoy ! -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
Re: [Pharo-dev] [squeak-dev] [ANN] Fuel 1.9.3
great job you guys sebastian o/ On 01/03/2014, at 02:23, Hernán Morales Durand hernan.mora...@gmail.com wrote: Thanks for the update. Cheers, Hernán 2014-02-26 18:13 GMT-03:00 Max Leske maxle...@gmail.com: Dear fellow Smalltalkers Mariano, Martin and myself are happy to announce Fuel version 1.9.3 which includes the follwing changes to 1.9 (1.9.1 and 1.9.2 were never officially announced): - (feature) the #fuelReplacement selector offers the ability to statically replace an object (e.g. with nil) during analysis. This can lead to significantly smaller graphs and improved speed when serializing large graphs - (feature) serialize the same graph that was analyzed instead of retrazing the graph during serialization. This prevents changes in the graph from happening between analysis and serialization - (change) store source when serializing CompiledMethod objects. Needed because Opal does not allow decompilation - (fix) migrate variables across hierarchy - (feature) ObjectserializeToFileNamed: shortcut for serializing arbitrary objects - (fix) better compression for LargeNegativeIntegers (https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteger-up-to-32bits-magnitude) Pharo30 already includes most of these changes (integration request: https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3). This release runs with: - Pharo: 1.1.1, 1.1.2, 1.2, 1.2.2, 1.3, 1.4, 2.0, 3.0 - Squeak: 4.1, 4.2, 4.3, 4.4, 4.5 The documentation is not up to date yet but we will remedy that situatoin within the next couple of days (http://rmod.lille.inria.fr/web/pier/software/Fuel). If you encounter any bugs or have suggestions, please contact us on the Fuel mailing list (http://lists.gforge.inria.fr/cgi-bin/mailman/roster/pharo-fuel) or create a new issue in our bug tracker (https://code.google.com/p/fuel/) We want to thank everyone who contributed to this release (by keyboard or opinion) and also all of those people who actively use Fuel. Cheers, Max
Re: [Pharo-dev] ws vs st extensions
Workspace serves a particular purpose. I use them, as soon as I depend on them I move it a to a method. However, the main use I have for them is startup scripts or other things I run from the command line. They can't be methods, because they change. Regards! ps: I have to read about the process of submitting a change Esteban A. Maringolo 2014-03-01 4:15 GMT-03:00 Pharo4Stef pharo4s...@free.fr: On 01 Mar 2014, at 00:17, Esteban A. Maringolo emaring...@gmail.com wrote: 2014-02-28 18:26 GMT-03:00 Chris Cunningham cunningham...@gmail.com: On Fri, Feb 28, 2014 at 6:07 AM, Esteban A. Maringolo emaring...@gmail.com wrote: I have a naive question... Why if the BasicCodeLoader handler looks for .st files does the Workpace offer .ws as the default extension? Well, the workspace doesn't just use chuck format - in fact, you rarely put in chunk format into a workspace (or do you? I certainly don't). Also, workspaces allow for dynamic local variables - which normal chunk loaders don't. The two things behave differently. .st is explicitly for runnable code - workspaces are for more than just code - more of a scratch pad. I know, but the cmd line handler isn't a chunk reader. It compiles the content of the file and evaluate it all at once. And explicitly expects for files with .st extension (I don't understand such restriction). I don't put chunk in a workspace either (actually I don't know how to properly read a chunk file in Pharo). tl;dr Frankly I don't like the .ws extension at all. It's a matter of habit. :) Regards! send a fix. For me saving workspace in file looks prehistorical age. just having method to manage code snippets is much more efficient Esteban A. Maringolo
[Pharo-dev] pharo --headless in Windows makes a Window show anyway
When running (from a Zeroconf install): pharo --headless Pharo.image it looks like that the window is not opening ( or it is opening and closing so fast that I do not see it). Then I have an image with Seaside, Magritte, and other things. When doing the same, I do see the window of one second and then it closes. Is it normal to have that window opening? That's annoying for scripts as it doesn't look good. On OSX I do not have this behavior. What causes that on Windows? Phil
[Pharo-dev] Versioneer docs?
I am now porting my code to 3.0 I am using Versioneer to look at my configuration as when I do load it in 3.0, it seems that there are some duplicate packages coming in my package-cache and I want to remove these dupes. (Mostly Seaside related). Versioneer is very helpful in representing the configuration. Now, is there any doc about its usage? TIA Phil
[Pharo-dev] Status of the VM?
Hi! Stef told me the coming VM will expose some data about the execution to the image. This will be great for our profiling tools. What is the status? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] pharo --headless in Windows makes a Window show anyway
On Sat, Mar 1, 2014 at 7:43 AM, p...@highoctane.be p...@highoctane.bewrote: When running (from a Zeroconf install): pharo --headless Pharo.image it looks like that the window is not opening ( or it is opening and closing so fast that I do not see it). Then I have an image with Seaside, Magritte, and other things. When doing the same, I do see the window of one second and then it closes. Is it normal to have that window opening? That's annoying for scripts as it doesn't look good. On OSX I do not have this behavior. What causes that on Windows? It's bits in the exe that decide whether it's a console app or a windows app. So, at least with the Cog VM, not sure about the Pharo VM, if you want to run headless you use the SqueakConsole.exe VM instead of the Squeak.exe VM. They're identical except in those bits. Yes the distinction is stupid; unix doesn't need it, but that's Windows. Phil -- best, Eliot
Re: [Pharo-dev] pharo --headless in Windows makes a Window show anyway
On Sat, Mar 1, 2014 at 5:12 PM, Eliot Miranda eliot.mira...@gmail.comwrote: On Sat, Mar 1, 2014 at 7:43 AM, p...@highoctane.be p...@highoctane.bewrote: When running (from a Zeroconf install): pharo --headless Pharo.image it looks like that the window is not opening ( or it is opening and closing so fast that I do not see it). Then I have an image with Seaside, Magritte, and other things. When doing the same, I do see the window of one second and then it closes. Is it normal to have that window opening? That's annoying for scripts as it doesn't look good. On OSX I do not have this behavior. What causes that on Windows? It's bits in the exe that decide whether it's a console app or a windows app. So, at least with the Cog VM, not sure about the Pharo VM, if you want to run headless you use the SqueakConsole.exe VM instead of the Squeak.exe VM. They're identical except in those bits. Yes the distinction is stupid; unix doesn't need it, but that's Windows. Phil -- best, Eliot So, there is a different way to build/link for each type in Squeak. Now, with Pharo, there is only one exe in Windows. Where's that thing in Squeak so that I can try to build the Pharo Windows headless version by kind of cloning it? In the CMakeLists.txt of the PharoVM for the Windows build, I do see: add_definitions(-march=pentium4 -mwindows -D_MT -msse2 -mthreads -mwin32 -mno-rtd -mms-bitfields -mno-accumulate-outgoing-args -D_USE_32BIT_TIME_T -D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -DWIN32 -DWIN32_FILE_SUPPORT -DNO_ISNAN -DNO_SERVICE -DNO_STD_FILE_SUPPORT -DLSB_FIRST -DVM_NAME=Pharo -DX86 -DSTACK_ALIGN_BYTES=16 -DALLOCA_LIES_SO_USE_GETSP=0 -DENABLE_FAST_BLT -g0 -O2 -march=pentium4 -momit-leaf-frame-pointer -maccumulate-outgoing-args -funroll-loops -DNDEBUG -DDEBUGVM=0) There are -mwindows and -mwin32 which look like candidates for that switch. What do I need to use? TIA Phil
Re: [Pharo-dev] ws vs st extensions
On Sat, Mar 1, 2014 at 7:21 AM, Esteban A. Maringolo emaring...@gmail.comwrote: Workspace serves a particular purpose. I use them, as soon as I depend on them I move it a to a method. However, the main use I have for them is startup scripts or other things I run from the command line. They can't be methods, because they change. +1. I use them for various things. One is for lots of different launch commands for the VM simulator, which I edit a little bit as I develop or debug. There are launch scripts for the various VMs, various images etc, with expressions to set breakpoints etc. Committing these to methods would end up with an unmanageable mess of methods used only once. Keeping a workspace full of a handful of these is much more manageable. Mine lives in my work image but saving it to a file is something I do occasionally, for example if I want to build a new work image, or remember some specific configuration. Another is for blog posts containing Smalltalk code. It's much easier to copy and paste colourised source into a workspace and convert this to html and paste once into wordpress than to colourise each method, export it and paste it into wordpress. The .ws extension is really useful because it says this is not source, its an arbitrary bag of expressions. So there's nothing archaic about this. As Esteban says it serves many different purposes that chunk format doesn't. With imagination it can serve new purposes (like the blog post editor). Regards! ps: I have to read about the process of submitting a change Esteban A. Maringolo 2014-03-01 4:15 GMT-03:00 Pharo4Stef pharo4s...@free.fr: On 01 Mar 2014, at 00:17, Esteban A. Maringolo emaring...@gmail.com wrote: 2014-02-28 18:26 GMT-03:00 Chris Cunningham cunningham...@gmail.com: On Fri, Feb 28, 2014 at 6:07 AM, Esteban A. Maringolo emaring...@gmail.com wrote: I have a naive question... Why if the BasicCodeLoader handler looks for .st files does the Workpace offer .ws as the default extension? Well, the workspace doesn't just use chuck format - in fact, you rarely put in chunk format into a workspace (or do you? I certainly don't). Also, workspaces allow for dynamic local variables - which normal chunk loaders don't. The two things behave differently. .st is explicitly for runnable code - workspaces are for more than just code - more of a scratch pad. I know, but the cmd line handler isn't a chunk reader. It compiles the content of the file and evaluate it all at once. And explicitly expects for files with .st extension (I don't understand such restriction). I don't put chunk in a workspace either (actually I don't know how to properly read a chunk file in Pharo). tl;dr Frankly I don't like the .ws extension at all. It's a matter of habit. :) Regards! send a fix. For me saving workspace in file looks prehistorical age. just having method to manage code snippets is much more efficient Esteban A. Maringolo -- best, Eliot
Re: [Pharo-dev] pharo --headless in Windows makes a Window show anyway
On Sat, Mar 1, 2014 at 8:31 AM, p...@highoctane.be p...@highoctane.bewrote: On Sat, Mar 1, 2014 at 5:12 PM, Eliot Miranda eliot.mira...@gmail.comwrote: On Sat, Mar 1, 2014 at 7:43 AM, p...@highoctane.be p...@highoctane.bewrote: When running (from a Zeroconf install): pharo --headless Pharo.image it looks like that the window is not opening ( or it is opening and closing so fast that I do not see it). Then I have an image with Seaside, Magritte, and other things. When doing the same, I do see the window of one second and then it closes. Is it normal to have that window opening? That's annoying for scripts as it doesn't look good. On OSX I do not have this behavior. What causes that on Windows? It's bits in the exe that decide whether it's a console app or a windows app. So, at least with the Cog VM, not sure about the Pharo VM, if you want to run headless you use the SqueakConsole.exe VM instead of the Squeak.exe VM. They're identical except in those bits. Yes the distinction is stupid; unix doesn't need it, but that's Windows. Phil -- best, Eliot So, there is a different way to build/link for each type in Squeak. Now, with Pharo, there is only one exe in Windows. Where's that thing in Squeak so that I can try to build the Pharo Windows headless version by kind of cloning it? In the CMakeLists.txt of the PharoVM for the Windows build, I do see: add_definitions(-march=pentium4 -mwindows -D_MT -msse2 -mthreads -mwin32 -mno-rtd -mms-bitfields -mno-accumulate-outgoing-args -D_USE_32BIT_TIME_T -D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -DWIN32 -DWIN32_FILE_SUPPORT -DNO_ISNAN -DNO_SERVICE -DNO_STD_FILE_SUPPORT -DLSB_FIRST -DVM_NAME=Pharo -DX86 -DSTACK_ALIGN_BYTES=16 -DALLOCA_LIES_SO_USE_GETSP=0 -DENABLE_FAST_BLT -g0 -O2 -march=pentium4 -momit-leaf-frame-pointer -maccumulate-outgoing-args -funroll-loops -DNDEBUG -DDEBUGVM=0) There are -mwindows and -mwin32 which look like candidates for that switch. What do I need to use? -mconsole in place of -mwindows -- best, Eliot
Re: [Pharo-dev] pharo --headless in Windows makes a Window show anyway
On Sat, Mar 1, 2014 at 8:35 AM, Eliot Miranda eliot.mira...@gmail.comwrote: On Sat, Mar 1, 2014 at 8:31 AM, p...@highoctane.be p...@highoctane.bewrote: On Sat, Mar 1, 2014 at 5:12 PM, Eliot Miranda eliot.mira...@gmail.comwrote: On Sat, Mar 1, 2014 at 7:43 AM, p...@highoctane.be p...@highoctane.bewrote: When running (from a Zeroconf install): pharo --headless Pharo.image it looks like that the window is not opening ( or it is opening and closing so fast that I do not see it). Then I have an image with Seaside, Magritte, and other things. When doing the same, I do see the window of one second and then it closes. Is it normal to have that window opening? That's annoying for scripts as it doesn't look good. On OSX I do not have this behavior. What causes that on Windows? It's bits in the exe that decide whether it's a console app or a windows app. So, at least with the Cog VM, not sure about the Pharo VM, if you want to run headless you use the SqueakConsole.exe VM instead of the Squeak.exe VM. They're identical except in those bits. Yes the distinction is stupid; unix doesn't need it, but that's Windows. Phil -- best, Eliot So, there is a different way to build/link for each type in Squeak. Now, with Pharo, there is only one exe in Windows. Where's that thing in Squeak so that I can try to build the Pharo Windows headless version by kind of cloning it? In the CMakeLists.txt of the PharoVM for the Windows build, I do see: add_definitions(-march=pentium4 -mwindows -D_MT -msse2 -mthreads -mwin32 -mno-rtd -mms-bitfields -mno-accumulate-outgoing-args -D_USE_32BIT_TIME_T -D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -DWIN32 -DWIN32_FILE_SUPPORT -DNO_ISNAN -DNO_SERVICE -DNO_STD_FILE_SUPPORT -DLSB_FIRST -DVM_NAME=Pharo -DX86 -DSTACK_ALIGN_BYTES=16 -DALLOCA_LIES_SO_USE_GETSP=0 -DENABLE_FAST_BLT -g0 -O2 -march=pentium4 -momit-leaf-frame-pointer -maccumulate-outgoing-args -funroll-loops -DNDEBUG -DDEBUGVM=0) There are -mwindows and -mwin32 which look like candidates for that switch. What do I need to use? -mconsole in place of -mwindows and of course if you start a console .exe on the desktop Windows creates a console window for it. sad... -- best, Eliot
Re: [Pharo-dev] Status of the VM?
Hello, This is true but this is a work in progress. Right now this feature is not stable. I will keep you in touch. I think in May I may have something stable enough (I will work with Eliot on April) but it will not be on the default VM. It will be available in the default pharo VM at some point but not now (maybe in a year ?). However, you may or may not be able to use it for your profiling tools. The idea is that you can get branch and send information from the previous executions of the method. However, the method needs to be cogged to have information available and once the cogged method is discarded the information is lost. It is really nice for hot spots but I don't know how it could work for a profiling tool. 2014-03-01 17:06 GMT+01:00 Alexandre Bergel alexandre.ber...@me.com: Hi! Stef told me the coming VM will expose some data about the execution to the image. This will be great for our profiling tools. What is the status? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [squeak-dev] [ANN] Fuel 1.9.3
So Debugger - Smalltalk tools debugger needed... Le 1 mars 2014 14:19, Sebastian Sastre sebast...@flowingconcept.com a écrit : great job you guys sebastian o/ On 01/03/2014, at 02:23, Hernán Morales Durand hernan.mora...@gmail.com wrote: Thanks for the update. Cheers, Hernán 2014-02-26 18:13 GMT-03:00 Max Leske maxle...@gmail.com: Dear fellow Smalltalkers Mariano, Martin and myself are happy to announce Fuel version 1.9.3 which includes the follwing changes to 1.9 (1.9.1 and 1.9.2 were never officially announced): - (feature) the #fuelReplacement selector offers the ability to statically replace an object (e.g. with nil) during analysis. This can lead to significantly smaller graphs and improved speed when serializing large graphs - (feature) serialize the same graph that was analyzed instead of retrazing the graph during serialization. This prevents changes in the graph from happening between analysis and serialization - (change) store source when serializing CompiledMethod objects. Needed because Opal does not allow decompilation - (fix) migrate variables across hierarchy - (feature) ObjectserializeToFileNamed: shortcut for serializing arbitrary objects - (fix) better compression for LargeNegativeIntegers ( https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteger-up-to-32bits-magnitude ) Pharo30 already includes most of these changes (integration request: https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3). This release runs with: - Pharo: 1.1.1, 1.1.2, 1.2, 1.2.2, 1.3, 1.4, 2.0, 3.0 - Squeak: 4.1, 4.2, 4.3, 4.4, 4.5 The documentation is not up to date yet but we will remedy that situatoin within the next couple of days ( http://rmod.lille.inria.fr/web/pier/software/Fuel). If you encounter any bugs or have suggestions, please contact us on the Fuel mailing list ( http://lists.gforge.inria.fr/cgi-bin/mailman/roster/pharo-fuel) or create a new issue in our bug tracker (https://code.google.com/p/fuel/) We want to thank everyone who contributed to this release (by keyboard or opinion) and also all of those people who actively use Fuel. Cheers, Max
Re: [Pharo-dev] Status of the VM?
Ok, thanks for the update. The VM is a formidable thing in which everything happen. Exposing to the image what’s going on in it is really pushing the innovation. Go go go! Alexandre On Mar 1, 2014, at 2:19 PM, Clément Bera bera.clem...@gmail.com wrote: Hello, This is true but this is a work in progress. Right now this feature is not stable. I will keep you in touch. I think in May I may have something stable enough (I will work with Eliot on April) but it will not be on the default VM. It will be available in the default pharo VM at some point but not now (maybe in a year ?). However, you may or may not be able to use it for your profiling tools. The idea is that you can get branch and send information from the previous executions of the method. However, the method needs to be cogged to have information available and once the cogged method is discarded the information is lost. It is really nice for hot spots but I don't know how it could work for a profiling tool. 2014-03-01 17:06 GMT+01:00 Alexandre Bergel alexandre.ber...@me.com: Hi! Stef told me the coming VM will expose some data about the execution to the image. This will be great for our profiling tools. What is the status? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Status of the VM?
On Sat, Mar 1, 2014 at 10:44 AM, Alexandre Bergel alexandre.ber...@me.comwrote: Ok, thanks for the update. The VM is a formidable thing in which everything happen. Exposing to the image what's going on in it is really pushing the innovation. The computer is a formidable thing in which everything happens ;-). The VM is just mechanism. The real magic is up in the image ;-). What's exciting about Clément's and my work is that it will allow adaptive optimization, so a much faster system, but that optimization will be done at the image level and will optimize from compiled methods to compiled methods with inlining, on-the-fly. So this optimization will /not/ be in the VM. No one's done this before so we really will be pushing innovation. Go go go! On y va! Alexandre On Mar 1, 2014, at 2:19 PM, Clément Bera bera.clem...@gmail.com wrote: Hello, This is true but this is a work in progress. Right now this feature is not stable. I will keep you in touch. I think in May I may have something stable enough (I will work with Eliot on April) but it will not be on the default VM. It will be available in the default pharo VM at some point but not now (maybe in a year ?). However, you may or may not be able to use it for your profiling tools. The idea is that you can get branch and send information from the previous executions of the method. However, the method needs to be cogged to have information available and once the cogged method is discarded the information is lost. It is really nice for hot spots but I don't know how it could work for a profiling tool. 2014-03-01 17:06 GMT+01:00 Alexandre Bergel alexandre.ber...@me.com: Hi! Stef told me the coming VM will expose some data about the execution to the image. This will be great for our profiling tools. What is the status? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- best, Eliot
Re: [Pharo-dev] Help needed! ClassTest#testRenaming
Nicolai Hess wrote:
Hope we can sort this out, more and more fixes suffer from the
wrong testing
failures and nothing new gets integrated.
12996
ClassTest#testRenaming leaves dirty package Dummy-Tests-Class
behind
12995 CI
ClassTest#testRenaming is failing
available options:
1. skip test
2. test for nil in
RPackageOrganizer#systemClassRenamedActionFrom:
before
rPackage updateDefinedClassNamed: oldName withNewName: newName.
3. review changes for issue 12601
(fix RPackageOrganizer#systemCategoryRemovedActionFrom:
ann, to
unregister packages even if there are MCPackages (don't know about
the
side effects)
best solution would be number 3, but the recent submissions for
issue 12601 are quite complex, so I don't know.
Nicolai
Here is something I was developing last week for
Case 12935 ManifestTests-leaving-dirty-packages
but I got distracted so its working but incomplete. It requires a
higher level architectural review as to whether this is a worthwhile
approach.
I had trouble understanding how to undo the state of the the dirty
package being left after test resources in the package were modified,
so following the engineering principle "if you can't solve the problem,
change the problem," I thought creating and deleting a temporary
package to hold the test resources would be less impact than dirtying
the existing packages. I also knew I could dig into the logic behind
the Monticello button +Package and package context menu item
[Unload package] to copy a working system. So far I have the following
(also attached as ST files)
"---"
Object subclass: #TemporaryTestResourceBuilder
instanceVariableNames: ''
classVariableNames: ''
category: 'Manifest-Tests'
"---"
TemporaryTestResourceBuilder class
instanceVariableNames: 'workingCopy'
"---"
TemporaryTestResourceBuildertemporaryTestPackageName
^ '-Temporary-Test-Resources-Manifest-Tests'.
"---"
TemporaryTestResourceBuilderdefineTemporaryPackage
RPackageOrganizer default registerPackageNamed: self packageName.
workingCopy := MCWorkingCopy forPackage: (MCPackage new name: self
packageName).
"---"
TemporaryTestResourceBuilderunloadTemporaryPackage
workingCopy unload.
"---"
TemporaryTestResourceBuilderdefineTemporaryMFClassA
"Define the class"
Object subclass: #MFClassA
instanceVariableNames: ''
classVariableNames: ''
category: self temporaryTestPackageName.
(Smalltalk at: #MFClassA) compileSilently: 'method
|foo|
self halt.
'.
^Smalltalk at: #MFClassA.
"---"
defineTemporaryMFClassB
"Define the class"
Object subclass: #MFClassB
instanceVariableNames: ''
classVariableNames: ''
category: self temporaryTestPackageName.
(Smalltalk at: #MFClassB) compileSilently: 'method2
|foo|
'.
(Smalltalk at: #MFClassB) compileSilently: 'method3
|foo|
self halt.
'.
^Smalltalk at: #MFClassB.
"--"
TestCase subclass: #SmalllintManifestCheckerTest
instanceVariableNames: 'checker mfClassA mfClassB'
classVariableNames: ''
category: 'Manifest-Tests'
"---"
SmalllintManifestCheckerTesttearDown
TemporaryTestResourceBuilder unloadTemporaryPackage.
"---"
SmalllintManifestCheckerTestsetUp
| bm |
TemporaryTestResourceBuilder defineTemporaryPackage.
mfClassA := TemporaryTestResourceBuilder defineTemporaryMFClassA.
mfClassB := TemporaryTestResourceBuilder defineTemporaryMFClassB.
"BTC: The following is unchanged except converting direct class
references to the instance variables"
bm := TheManifestBuilder of: mfClassA.
bm installFalsePositiveOf: RBCodeCruftLeftInMethodsRule
uniqueIdentifierName version: 1.
bm addFalsePositive: mfClassB #method3 of:
RBCodeCruftLeftInMethodsRule uniqueIdentifierName version: 1.
bm installToDoOf: RBOnlyReadOrWrittenTemporaryRule
uniqueIdentifierName version: 1.
bm
addAllToDo:
{(mfClassB #method3).
(mfClassA #method)}
of: RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName
version: 1.
checker := SmalllintManifestChecker new
"---"
SmalllintManifestCheckerTesttestIsFalsePositive
"BTC: No changes here except converting direct class references to
instance variables"
| rule |
rule := RBCompositeLintRule allGoodRules.
checker
rule: rule;
environment: self package asEnvironment;
run.
self assert: (checker isFalsePositive: (mfClassB#method3)
forRuleId: (RBCodeCruftLeftInMethodsRule uniqueIdentifierName)
versionId: 1).
self deny: (checker isFalsePositive: (mfClassA#method)
forRuleId: (RBCodeCruftLeftInMethodsRule uniqueIdentifierName)
versionId: 1).
"--"
Now the following test executed from Workspace works fine...
SmalllintManifestCheckerTest new setUp testIsFalsePositive tearDown.
"--"
Some reflection on this:
* TemporaryTestResourceBuilder class-side stuff
Re: [Pharo-dev] Status of the VM?
Excellent! Eager to try it!!! Alexandre Le 01-03-2014 à 16:01, Eliot Miranda eliot.mira...@gmail.com a écrit : On Sat, Mar 1, 2014 at 10:44 AM, Alexandre Bergel alexandre.ber...@me.com wrote: Ok, thanks for the update. The VM is a formidable thing in which everything happen. Exposing to the image what’s going on in it is really pushing the innovation. The computer is a formidable thing in which everything happens ;-). The VM is just mechanism. The real magic is up in the image ;-). What's exciting about Clément's and my work is that it will allow adaptive optimization, so a much faster system, but that optimization will be done at the image level and will optimize from compiled methods to compiled methods with inlining, on-the-fly. So this optimization will /not/ be in the VM. No one's done this before so we really will be pushing innovation. Go go go! On y va! Alexandre On Mar 1, 2014, at 2:19 PM, Clément Bera bera.clem...@gmail.com wrote: Hello, This is true but this is a work in progress. Right now this feature is not stable. I will keep you in touch. I think in May I may have something stable enough (I will work with Eliot on April) but it will not be on the default VM. It will be available in the default pharo VM at some point but not now (maybe in a year ?). However, you may or may not be able to use it for your profiling tools. The idea is that you can get branch and send information from the previous executions of the method. However, the method needs to be cogged to have information available and once the cogged method is discarded the information is lost. It is really nice for hot spots but I don't know how it could work for a profiling tool. 2014-03-01 17:06 GMT+01:00 Alexandre Bergel alexandre.ber...@me.com: Hi! Stef told me the coming VM will expose some data about the execution to the image. This will be great for our profiling tools. What is the status? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- best, Eliot
Re: [Pharo-dev] Status of the VM?
Hi: On 01 Mar 2014, at 19:44, Alexandre Bergel alexandre.ber...@me.com wrote: The VM is a formidable thing in which everything happen. Exposing to the image what’s going on in it is really pushing the innovation. Perhaps something that could be relevant in case someone decides to implement such an interface in Cog: Just one, pretty old example: http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#EventIndex You can get access to many different information in terms of ‘events’ on the JVM. For building a profiler, more than sufficient. And, at least in my personal opinion also something that would be desirable for Cog, perhaps in a slightly more modern design, but with a similar flavor. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
Re: [Pharo-dev] Status of the VM?
Hi Stefan, On Sat, Mar 1, 2014 at 12:55 PM, Stefan Marr smallt...@stefan-marr.dewrote: Hi: On 01 Mar 2014, at 19:44, Alexandre Bergel alexandre.ber...@me.com wrote: The VM is a formidable thing in which everything happen. Exposing to the image what's going on in it is really pushing the innovation. Perhaps something that could be relevant in case someone decides to implement such an interface in Cog: Just one, pretty old example: http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#EventIndex Interesting list. Assuming the list refers to events one can handle in Smalltalk, then let me go through these and see which we need, don't need or already have: Event Index - Breakpointhttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#Breakpoint we already have this. An illegal bytecode will send an error message to the current context. See my MethodMassage package. We use this at Cadence to implement coverage. - Class File Load Hookhttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassFileLoadHook not needed. classes are loaded by Smalltalk code, not the VM. - *Class Load http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassLoad* not needed. ditto - *Class Prepare http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassPrepare* not needed. ditto - *Compiled Method Load http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMethodLoad* not needed. methods are loaded by Smalltalk code, not the VM. - *Compiled Method Unload http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMethodUnload* not needed. ditto - Data Dump Requesthttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DataDumpRequest to what extent is snapshot adequate? Has been used for adequate image debugging (and of course we can serialize processes so people are using things like Fuel to save the stack traces of processes that encounter errors). Not adequate for VM debugging: the heap may be invalid and not saveable; shapshot load does more than merely fill memory; it swizzles etc, and these operations can and will fail on an invalid heap. Personally I think things like -blockOnError which causes the VM to block rather than exit on error, allowing one to attach gdb to a crashed VM process is more useful. - *Dynamic Code Generated http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DynamicCodeGenerated* not needed. methods are loaded by Smalltalk code, not the VM. - *Exception http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#Exception* not needed. Smalltalk's exception system has resume semantics, not retry, so there's no need to ask to see an exception at source; the source of the exception can be examined after the fact (unlike Java, which has restart semantics). In fact folks like Avi Bryant (and I believe him) think that the business opportunity with hadoop/map-reduce is indeed Smalltalk's exception semantics which allow live debugging of errors. - *Exception Catch http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ExceptionCatch* not needed. ditto - Field Accesshttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FieldAccess Quite possibly. If one is using classical Smalltalk there is no linguistic hook for field access. With Pharo's slots then presumably transforming methods to insert traps on field access is trivial (and databases like GemStone have done similar things with brute bytecode manipulation). With Newspeak, which has no direct inst var access, this can be subsumed by MethodEntry (see below). So whether this is needed or not depends on either language evolution or good bytecode manipulation tools; if these are available this is not needed. - Field Modificationhttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FieldModification Quite possibly. Again the approaches outlined above can be done (as gemStone has done in the past). But we nearly have this. I've implemented per-instance immutability for the old Newspeak VM (a variant of the Squeak interpreter) and this is easy to fold into Cog (and indeed the Interpreter VM). GemStone engineers prefer per-instance immutability than their own bytecode modification. I think I agree. I'd rather depend on immutability (which has other uses such as immutable literals) than a special VM hook. - Frame Pophttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FramePop Hmm. Possibly. IIRC, I think method wrappers provide a manageable way to do this. - Garbage Collection Finishhttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageCollectionFinish Indeed. There are hacks to get this. Further there are many ways to implement this. e.g. is it a callback on finishing a form
Re: [Pharo-dev] [squeak-dev] [ANN] Fuel 1.9.3
On 01.03.2014, at 18:46, p...@highoctane.be wrote: So Debugger - Smalltalk tools debugger needed... Thanks Phil, I missed that somehow. Debugger is now SpecDebugger. I’ll fix it. Le 1 mars 2014 14:19, Sebastian Sastre sebast...@flowingconcept.com a écrit : great job you guys sebastian o/ On 01/03/2014, at 02:23, Hernán Morales Durand hernan.mora...@gmail.com wrote: Thanks for the update. Cheers, Hernán 2014-02-26 18:13 GMT-03:00 Max Leske maxle...@gmail.com: Dear fellow Smalltalkers Mariano, Martin and myself are happy to announce Fuel version 1.9.3 which includes the follwing changes to 1.9 (1.9.1 and 1.9.2 were never officially announced): - (feature) the #fuelReplacement selector offers the ability to statically replace an object (e.g. with nil) during analysis. This can lead to significantly smaller graphs and improved speed when serializing large graphs - (feature) serialize the same graph that was analyzed instead of retrazing the graph during serialization. This prevents changes in the graph from happening between analysis and serialization - (change) store source when serializing CompiledMethod objects. Needed because Opal does not allow decompilation - (fix) migrate variables across hierarchy - (feature) ObjectserializeToFileNamed: shortcut for serializing arbitrary objects - (fix) better compression for LargeNegativeIntegers (https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteger-up-to-32bits-magnitude) Pharo30 already includes most of these changes (integration request: https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3). This release runs with: - Pharo: 1.1.1, 1.1.2, 1.2, 1.2.2, 1.3, 1.4, 2.0, 3.0 - Squeak: 4.1, 4.2, 4.3, 4.4, 4.5 The documentation is not up to date yet but we will remedy that situatoin within the next couple of days (http://rmod.lille.inria.fr/web/pier/software/Fuel). If you encounter any bugs or have suggestions, please contact us on the Fuel mailing list (http://lists.gforge.inria.fr/cgi-bin/mailman/roster/pharo-fuel) or create a new issue in our bug tracker (https://code.google.com/p/fuel/) We want to thank everyone who contributed to this release (by keyboard or opinion) and also all of those people who actively use Fuel. Cheers, Max
Re: [Pharo-dev] Status of the VM?
Hey, It's fun because I looked at the JVM list and most point looked irrelevant as you described. It seems that the only thing we miss is the GC hook: we could have a selector in special object array to call at each GC on the 'Smalltalk' object to trigger a method in the image that would be by default an empty method. Field access is a solved problem with slots, definitely. 2014-03-01 22:35 GMT+01:00 Eliot Miranda eliot.mira...@gmail.com: Hi Stefan, On Sat, Mar 1, 2014 at 12:55 PM, Stefan Marr smallt...@stefan-marr.dewrote: Hi: On 01 Mar 2014, at 19:44, Alexandre Bergel alexandre.ber...@me.com wrote: The VM is a formidable thing in which everything happen. Exposing to the image what's going on in it is really pushing the innovation. Perhaps something that could be relevant in case someone decides to implement such an interface in Cog: Just one, pretty old example: http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#EventIndex Interesting list. Assuming the list refers to events one can handle in Smalltalk, then let me go through these and see which we need, don't need or already have: Event Index - Breakpointhttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#Breakpoint we already have this. An illegal bytecode will send an error message to the current context. See my MethodMassage package. We use this at Cadence to implement coverage. - Class File Load Hookhttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassFileLoadHook not needed. classes are loaded by Smalltalk code, not the VM. - *Class Load http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassLoad* not needed. ditto - *Class Prepare http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassPrepare* not needed. ditto - *Compiled Method Load http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMethodLoad* not needed. methods are loaded by Smalltalk code, not the VM. - *Compiled Method Unload http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMethodUnload* not needed. ditto - Data Dump Requesthttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DataDumpRequest to what extent is snapshot adequate? Has been used for adequate image debugging (and of course we can serialize processes so people are using things like Fuel to save the stack traces of processes that encounter errors). Not adequate for VM debugging: the heap may be invalid and not saveable; shapshot load does more than merely fill memory; it swizzles etc, and these operations can and will fail on an invalid heap. Personally I think things like -blockOnError which causes the VM to block rather than exit on error, allowing one to attach gdb to a crashed VM process is more useful. - *Dynamic Code Generated http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DynamicCodeGenerated* not needed. methods are loaded by Smalltalk code, not the VM. - *Exception http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#Exception* not needed. Smalltalk's exception system has resume semantics, not retry, so there's no need to ask to see an exception at source; the source of the exception can be examined after the fact (unlike Java, which has restart semantics). In fact folks like Avi Bryant (and I believe him) think that the business opportunity with hadoop/map-reduce is indeed Smalltalk's exception semantics which allow live debugging of errors. - *Exception Catch http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ExceptionCatch* not needed. ditto - Field Accesshttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FieldAccess Quite possibly. If one is using classical Smalltalk there is no linguistic hook for field access. With Pharo's slots then presumably transforming methods to insert traps on field access is trivial (and databases like GemStone have done similar things with brute bytecode manipulation). With Newspeak, which has no direct inst var access, this can be subsumed by MethodEntry (see below). So whether this is needed or not depends on either language evolution or good bytecode manipulation tools; if these are available this is not needed. - Field Modificationhttp://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FieldModification Quite possibly. Again the approaches outlined above can be done (as gemStone has done in the past). But we nearly have this. I've implemented per-instance immutability for the old Newspeak VM (a variant of the Squeak interpreter) and this is easy to fold into Cog (and indeed the Interpreter VM). GemStone engineers prefer per-instance immutability than their own bytecode modification. I think I agree. I'd rather
Re: [Pharo-dev] Status of the VM?
Maybe I'm missing something obvious, but from my point of view the fundamental difference here is that with JVM's JPDA triggering of event actually **does not** affect the monitored system. If these events are handled by the image, it is quite tricky to figure out which one is caused by application and which one is caused by the event handling machinery. For instance, if (non-empty) method is called after a GC, this handler may trigger another GC, which may... That brings me to another, if you do in-image profiling (event handling), data could be quite different than what would you get using out-of-image profiler. personal experience: I've used (and implemented some :-) both - Smalltalk in-image tools and out-of-image tools, namely JPDA and DTRACE/STAP. For serious profiling and monitoring, I always use out-of-image approach if possible. Jan On 01/03/14 23:34, Clément Bera wrote: Hey, It's fun because I looked at the JVM list and most point looked irrelevant as you described. It seems that the only thing we miss is the GC hook: we could have a selector in special object array to call at each GC on the 'Smalltalk' object to trigger a method in the image that would be by default an empty method. Field access is a solved problem with slots, definitely. 2014-03-01 22:35 GMT+01:00 Eliot Miranda eliot.mira...@gmail.com mailto:eliot.mira...@gmail.com: Hi Stefan, On Sat, Mar 1, 2014 at 12:55 PM, Stefan Marr smallt...@stefan-marr.de mailto:smallt...@stefan-marr.de wrote: Hi: On 01 Mar 2014, at 19:44, Alexandre Bergel alexandre.ber...@me.com mailto:alexandre.ber...@me.com wrote: The VM is a formidable thing in which everything happen. Exposing to the image what’s going on in it is really pushing the innovation. Perhaps something that could be relevant in case someone decides to implement such an interface in Cog: Just one, pretty old example: http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#EventIndex Interesting list. Assuming the list refers to events one can handle in Smalltalk, then let me go through these and see which we need, don't need or already have: Event Index * Breakpoint http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#Breakpoint we already have this. An illegal bytecode will send an error message to the current context. See my MethodMassage package. We use this at Cadence to implement coverage. * Class File Load Hook http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassFileLoadHook not needed. classes are loaded by Smalltalk code, not the VM. * *Class Load http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassLoad* not needed. ditto * *Class Prepare http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassPrepare* not needed. ditto * *Compiled Method Load http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMethodLoad* not needed. methods are loaded by Smalltalk code, not the VM. * *Compiled Method Unload http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMethodUnload* not needed. ditto * Data Dump Request http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DataDumpRequest to what extent is snapshot adequate? Has been used for adequate image debugging (and of course we can serialize processes so people are using things like Fuel to save the stack traces of processes that encounter errors). Not adequate for VM debugging: the heap may be invalid and not saveable; shapshot load does more than merely fill memory; it swizzles etc, and these operations can and will fail on an invalid heap. Personally I think things like -blockOnError which causes the VM to block rather than exit on error, allowing one to attach gdb to a crashed VM process is more useful. * *Dynamic Code Generated http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DynamicCodeGenerated* not needed. methods are loaded by Smalltalk code, not the VM. * *Exception http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#Exception* not needed. Smalltalk's exception system has resume semantics, not retry, so there's no need to ask to see an exception at source; the source of the exception can be examined after the fact (unlike Java, which has restart semantics). In fact folks like Avi Bryant (and I believe him) think that the business opportunity with hadoop/map-reduce is indeed Smalltalk's exception semantics which allow live debugging of errors. * *Exception Catch
[Pharo-dev] Zinc bug submitting form via GET?
In porting the Mechanize web scraping library from Ruby, I started with the
following example:
a.get('http://google.com/') do |page|
search_result = page.form_with(:name = 'f') do |search|
search.q = 'Hello world'
end.submit
It GETs
http://www.google.com/search?ie=ISO-8859-1hl=ensource=hpq=Hello+worldgbv=1
I tried to do that with Zinc via formAt: name put:, but when I sent #get,
the query was empty and the response was another blank search form. It took
me some time to figure out what was going on and change to #queryPut:at: in
the GET case, but now I'm managing form logic from the outside. Since GET is
valid for forms (apparently it is the default per
http://www.w3schools.com/tags/att_form_method.asp), it seems Zinc should
handle this more gracefully. I would expect it to check for form fields and
add them to the query when doing a GET. What do you think?
n.b. Gofer it
smalltalkhubUser: 'SeanDeNigris' project: 'Mechanize';
package: 'Mechanize';
load.
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/Zinc-bug-submitting-form-via-GET-tp4747276.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Help needed! ClassTest#testRenaming
Pharo4Stef wrote: Hope we can sort this out, more and more fixes suffer from the wrong testing failures and nothing new gets integrated. yes I’m sorry about that. Marcus is burnt out. Esteban is on vacation and I’m out of time managing our team and other duties. For the issues related to rpackage I will let esteban looked at them because he worked a lot on them. I see there is progress on Case 12995 with a monkey validated solution that modifies... RPackageOrganizersystemCategoryRemovedActionFrom:. I have an alternate monkey validated solution on Case 13021 that modifies... CompiledMethodTesttestIsInstalled CompiledMethodTesttestMethodClass CompiledMethodTesttestSearchForClass CompiledMethodTesttestSearchForSelector CompiledMethodTesttestSelector Case 12995 is probably required anyway and may make 13021 unnecessary, but 13021 seems lower risk and to clear the way for other pending resolved cases maybe faster to integrate - depending on how much more consideration 12995 needs. Anyway, looks like there is soon a way forward. cheers -ben 12996 ClassTest#testRenaming leaves dirty package Dummy-Tests-Class behind 12995 CI ClassTest#testRenaming is failing available options: 1. skip test 2. test for nil in RPackageOrganizer#systemClassRenamedActionFrom: before rPackage updateDefinedClassNamed: oldName withNewName: newName. 3. review changes for issue 12601 (fix RPackageOrganizer#systemCategoryRemovedActionFrom: ann, to unregister packages even if there are MCPackages (don't know about the side effects) best solution would be number 3, but the recent submissions for issue 12601 are quite complex, so I don't know. Nicolai
