March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Status of the VM?

by Alexandre Bergel

Excellent! Eager to try it!!! Alexandre > Le 01-03-2014 Ã 16:01, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > > > > >> On Sat, Mar 1, 2014 at 10:44 AM, Alexandre Bergel <alexandre.bergel(a)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.clement(a)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.bergel(a)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

March 1, 2014

Re: [Pharo-dev] Help needed! ClassTest>>#testRenaming

by btc＠openinworld.com

'From Pharo3.0 of 18 March 2013 [Latest update: #30778] on 1 March 2014 at 10:10:40.919902 am'! Object subclass: #TemporaryTestResourceBuilder instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Manifest-Tests'! !TemporaryTestResourceBuilder commentStamp: '<historical>' prior: 0! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! TemporaryTestResourceBuilder class instanceVariableNames: 'workingCopy'! !TemporaryTestResourceBuilder class commentStamp: '<historical>' prior: 0! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:27'! temporaryTestPackageName ^ 'ZZZZ-Dynamic-Manifest-Tests-Resources'.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:28'! defineTemporaryPackage RPackageOrganizer default registerPackageNamed: self temporaryTestPackageName. workingCopy := MCWorkingCopy forPackage: (MCPackage new name: self temporaryTestPackageName). ! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 10:01'! defineTemporaryMFClassA "Define the class" Object subclass: #MFClassA instanceVariableNames: '' classVariableNames: '' category: self temporaryTestPackageName. (Smalltalk at: #MFClassA) compileSilently: 'method |foo| self halt. '. ^Smalltalk at: #MFClassA.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 2/24/2014 01:46'! unloadTemporaryPackage workingCopy unload.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:26'! testPackageName ^ 'ZZZZ-Dynamic-Manifest-Tests-Resources'.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 10:01'! 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.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:27'! temporaryTestPackageName ^ 'ZZZZ-Dynamic-Manifest-Tests-Resources'.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:28'! defineTemporaryPackage RPackageOrganizer default registerPackageNamed: self temporaryTestPackageName. workingCopy := MCWorkingCopy forPackage: (MCPackage new name: self temporaryTestPackageName). ! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 10:01'! defineTemporaryMFClassA "Define the class" Object subclass: #MFClassA instanceVariableNames: '' classVariableNames: '' category: self temporaryTestPackageName. (Smalltalk at: #MFClassA) compileSilently: 'method |foo| self halt. '. ^Smalltalk at: #MFClassA.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 2/24/2014 01:46'! unloadTemporaryPackage workingCopy unload.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:26'! testPackageName ^ 'ZZZZ-Dynamic-Manifest-Tests-Resources'.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 10:01'! 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.! ! 'From Pharo3.0 of 18 March 2013 [Latest update: #30778] on 1 March 2014 at 10:10:35.531902 am'! TestCase subclass: #SmalllintManifestCheckerTest instanceVariableNames: 'checker mfClassA mfClassB' classVariableNames: '' poolDictionaries: '' category: 'Manifest-Tests'! !SmalllintManifestCheckerTest commentStamp: 'TorstenBergmann 2/19/2014 08:34' prior: 0! SUnit tests for SmalllintManifestChecker! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:45'! testToDoOf | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (( checker toDoOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassB>>#method3)]). self deny: (( checker toDoOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassB>>#method2)]).! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:56'! testIsToDo | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (checker isToDo: (mfClassB>>#method3) forRuleId: (RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName) versionId: 1). self deny: (checker isToDo: (mfClassB>>#method2) forRuleId: (RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName) versionId: 1). ! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:57'! testCriticsOf | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new) size = 3. self assert: (( checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new ) anySatisfy: [:each| each = (mfClassB>>#method3)]). self assert: (( checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassA>>#method)]).! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:56'! testIsFalsePositive | 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). ! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'StephaneDucasse 3/21/2013 13:51'! cleaningResources Smalltalk globals at: #ManifestManifestResourcesTests ifPresent: [ :cl | cl removeFromChanges; removeFromSystemUnlogged ]! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'BenComan 3/1/2014 10:02'! setUp | bm | " self cleaningResources. " TemporaryTestResourceBuilder defineTemporaryPackage. mfClassA := TemporaryTestResourceBuilder defineTemporaryMFClassA. mfClassB := TemporaryTestResourceBuilder defineTemporaryMFClassB. 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! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'BenComan 3/1/2014 09:51'! tearDown TemporaryTestResourceBuilder unloadTemporaryPackage.! ! !SmalllintManifestCheckerTest methodsFor: 'private' stamp: 'BenComan 2/24/2014 01:59'! package MCWorkingCopy managersForClass: mfClassA do: [:p | ^ p packageSet packages first]. " should be equivalent to RPackageOrganizer default packageNamed: #'Manifest-Resources-Tests' "! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:45'! testToDoOf | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (( checker toDoOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassB>>#method3)]). self deny: (( checker toDoOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassB>>#method2)]).! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:56'! testIsToDo | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (checker isToDo: (mfClassB>>#method3) forRuleId: (RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName) versionId: 1). self deny: (checker isToDo: (mfClassB>>#method2) forRuleId: (RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName) versionId: 1). ! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:57'! testCriticsOf | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new) size = 3. self assert: (( checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new ) anySatisfy: [:each| each = (mfClassB>>#method3)]). self assert: (( checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassA>>#method)]).! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:56'! testIsFalsePositive | 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). ! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'StephaneDucasse 3/21/2013 13:51'! cleaningResources Smalltalk globals at: #ManifestManifestResourcesTests ifPresent: [ :cl | cl removeFromChanges; removeFromSystemUnlogged ]! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'BenComan 3/1/2014 10:02'! setUp | bm | " self cleaningResources. " TemporaryTestResourceBuilder defineTemporaryPackage. mfClassA := TemporaryTestResourceBuilder defineTemporaryMFClassA. mfClassB := TemporaryTestResourceBuilder defineTemporaryMFClassB. 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! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'BenComan 3/1/2014 09:51'! tearDown TemporaryTestResourceBuilder unloadTemporaryPackage.! ! !SmalllintManifestCheckerTest methodsFor: 'private' stamp: 'BenComan 2/24/2014 01:59'! package MCWorkingCopy managersForClass: mfClassA do: [:p | ^ p packageSet packages first]. " should be equivalent to RPackageOrganizer default packageNamed: #'Manifest-Resources-Tests' "! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! SmalllintManifestCheckerTest class instanceVariableNames: 'mfClassA'! !SmalllintManifestCheckerTest class commentStamp: '<historical>' prior: 0! ! !SmalllintManifestCheckerTest class methodsFor: 'as yet unclassified' stamp: 'BenComan 2/24/2014 01:59'! DoIt ^ MCWorkingCopy managersForClass: mfClassA do: [:p | ^ p first] ! ! !SmalllintManifestCheckerTest class methodsFor: 'as yet unclassified' stamp: 'BenComan 2/24/2014 01:59'! DoIt ^ MCWorkingCopy managersForClass: mfClassA do: [:p | ^ p first] ! !

March 1, 2014

Re: [Pharo-dev] Status of the VM?

by Eliot Miranda

On Sat, Mar 1, 2014 at 10:44 AM, Alexandre Bergel <alexandre.bergel(a)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.clement(a)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.bergel(a)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

March 1, 2014

Re: [Pharo-dev] Status of the VM?

by Alexandre Bergel

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.clement(a)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.bergel(a)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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 1, 2014

Re: [Pharo-dev] [squeak-dev] [ANN] Fuel 1.9.3

by phil＠highoctane.be

So Debugger -> Smalltalk tools debugger needed... Le 1 mars 2014 14:19, "Sebastian Sastre" <sebastian(a)flowingconcept.com> a Ã©crit : > great job you guys > > sebastian > > o/ > > On 01/03/2014, at 02:23, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > Thanks for the update. > Cheers, > > HernÃ¡n > > > 2014-02-26 18:13 GMT-03:00 Max Leske <maxleske(a)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) Object>>serializeToFileNamed: shortcut for serializing >> arbitrary objects >> - (fix) better compression for LargeNegativeIntegers ( >> https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteg… >> ) >> >> 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 >> > >

March 1, 2014

Re: [Pharo-dev] Status of the VM?

by ClÃ©ment Bera

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.bergel(a)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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

March 1, 2014

Re: [Pharo-dev] pharo --headless in Windows makes a Window show anyway

by Eliot Miranda

On Sat, Mar 1, 2014 at 8:35 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Sat, Mar 1, 2014 at 8:31 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> On Sat, Mar 1, 2014 at 5:12 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >> >>> >>> >>> >>> On Sat, Mar 1, 2014 at 7:43 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: >>> >>>> 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

March 1, 2014

Re: [Pharo-dev] pharo --headless in Windows makes a Window show anyway

by Eliot Miranda

On Sat, Mar 1, 2014 at 8:31 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > On Sat, Mar 1, 2014 at 5:12 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> >> On Sat, Mar 1, 2014 at 7:43 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: >> >>> 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

March 1, 2014

Re: [Pharo-dev] ws vs st extensions

by Eliot Miranda

On Sat, Mar 1, 2014 at 7:21 AM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > 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 <pharo4Stef(a)free.fr>: > > > > On 01 Mar 2014, at 00:17, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > >> 2014-02-28 18:26 GMT-03:00 Chris Cunningham <cunningham.cb(a)gmail.com>: > >>> On Fri, Feb 28, 2014 at 6:07 AM, Esteban A. Maringolo < > emaringolo(a)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

March 1, 2014

Re: [Pharo-dev] pharo --headless in Windows makes a Window show anyway

by phil＠highoctane.be

On Sat, Mar 1, 2014 at 5:12 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Sat, Mar 1, 2014 at 7:43 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> 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

March 1, 2014