- Pharo-dev - lists.pharo.org

FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform, during save after initial load (pharo5.0)

by Dale Henrichs

I could have sworn this was working last week, but now I can't load the UnifiedFFI project. Here's the stack ... note that this appears to be breaking during a SmalltalkImage>>saveAs: call that I make after loading a project that depends up UnifiedFFI during a batch job ...: FFICallback class>>isForCurrentPlatform FFICallback class(Object)>>doesNotUnderstand: #isForCurrentPlatform [ :subclass | subclass isForCurrentPlatform ] in Callback class>>startUp: in Block: [ :subclass | subclass isForCurrentPlatform ] [ :each | (aBlock value: each) ifTrue: [ ^ foundBlock cull: each ] ] in Array(Collection)>>detect:ifFound:ifNone: in Block: [ :each | ... Array(SequenceableCollection)>>do: Array(Collection)>>detect:ifFound:ifNone: Array(Collection)>>detect:ifNone: Callback class>>startUp: ClassSessionHandler>>startup: [ :each | each startup: isImageStarting ] in WorkingSession>>runStartup: in Block: [ :each | each startup: isImageStarting ] [ aBlock value: each ] in [ :each | [ aBlock value: each ] on: Exception do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ aBlock value: each ] BlockClosure>>on:do: [ :each | [ aBlock value: each ] on: Exception do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ :each | ... Array(SequenceableCollection)>>do: WorkingSession>>runList:do: WorkingSession>>runStartup: WorkingSession>>start: SessionManager>>snapshot:andQuit: SmalltalkImage>>snapshot:andQuit: SmalltalkImage>>saveImageInFileNamed: SmalltalkImage>>saveAs: SaveCommandLineHandler>>saveImage SaveCommandLineHandler>>activate SaveCommandLineHandler class(CommandLineHandler class)>>activateWith: [ aCommandLinehandler activateWith: commandLine ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ] BlockClosure>>on:do: PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: [ self handleArgument: (self arguments ifEmpty: [ '' ] ifNotEmpty: [ :arguments | arguments first ]) ] in PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self... BlockClosure>>on:do:

June 27, 2016

Re: [Pharo-dev] Having comments for pragma?

by Eliot Miranda

Hi Doru, On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Eliot, > > I agree with most things you say (except the conclusion :)), and I think > that we are talking about complementary issues. > > As I mentioned before, there already is a need to distinguish between a > plain selector and one that is associated with pragmas. This is what you > find in PragmaType in Spotter and Inspector. This is a kind of meta-object > and having it adds value. I can search for pragmas âtypeâ (we can also call > it a PragmaSelector), and I can distinguish between all occurrences of a > pragma âtypeâ and its utilization in computation. But, the current > implementation of PragmaType is a mere pseudo-meta-object, given that it > has no casual connection to the runtime. > > What we know from Smalltalk is that the analysis model does not have to > differ from the runtime one. The consequence is that every time we do see a > difference, we should investigate because we might uncover a hidden need > opportunity. > > I know the VW model, and indeed, we could have something like: > > MyConcept class>>myPragmaDefinition > âa comment about the pragma" > <pragma: #selector> > > However, this only deals with the definition of the pragma type not with > the internal representation. There could still well be an object that > encapsulates both the selector and the comment. And that object would also > allow us to build tools around it. We could call it a PragmaType, > PragmaDefinition, or even PragmaSelector. And we could get the Pragma to > point to this type either through an inst var or through a query (I would > probably prefer an instvar). > Well, there already /is/ a meta-object called Pragma, and it gets instantiated when one accesses the compiled method via pragmas: (CompiledMethod allInstances detect: [:m| m pragmas size > 1]) pragmas collect: [:ea| {ea. ea class}] {{<export: true> . Pragma} . {<var: #tablePtr type: 'int *'> . Pragma}} So we could add the information you want to Pragma, and have it be lazy. The Pragma could go search for the defining class-side pragma methods and use the parser to extract the comment(s) when asked. Hence simple access to pragmas, interested only in the selectors for applying, wouldn't have their performance be impacted. > I think that this proposition does not remove from the simplicity of the > implementation at all, but allows the new needs to be accommodated nicely. > The alternative is to not do anything, in which case we will continue to > have an analysis-only-pseudo-meta-object which is not nice at all. I do not > think we should jump on this lightly, but I do think we should have a > critical look and evaluate the options. > This pseudo-meta-object (Pragma) can sty ill be causally connected, in the same way that a MethodReference can be causally connected. The causation is things like "remove", "recompile", but that's dubious. It's essentially a read-only relationship; one wants to be able to locate the method from the pragma, but changing the method from the pragma isn't necessarily a good idea. Would you agree that convenience methods like "remove" on MethodReference are a bad idea and one should stick to the removeSelector: protocol on Behavior and ClassDescription? > What do you think? > Have I and enough coffee to scramble my thoughts might be a more pertinent question ;-) > > Cheers, > Doru > > > > On Jun 27, 2016, at 2:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > Hi Doru, > > > >> On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Hi, > >> > >> The CompiledMethod already has a way to retrieve Pragma instances: > >> > >> CompiledMethod>>pragmas. > >> > >> However, the Pragma instance does not have a meta-object associated > with it. So, I would first start from adding that one and linking such a > PragmaType to its instances. The important thing here would be that all > Pragma instances with a certain selector should reference the same > PragmaType. > > > > Let me express a dissenting opinion. Our pragma system is minimal yet > powerful. By using Message instances (with literal arguments) to represent > pragmas we get > > - executable pragmas that can be applied using perform: or wrappers such > as sentTo: > > - we can use conventional browsing queries (implementors and senders) to > discover which methods are marked by a specific pragma and what > pragma-processing tools implement a specific pragma. > > - a rich pragma language that can have many, named parameters > > - a system which doesn't need its own language, but reuses the existing > Smalltalk parsing facilities, and so is easier to learn and to implement > > > > So its parsimony is an important part of its virtues. It is minimal. > > > > One thing missing from the Squeak/Pharo implementation is the set of > legal pragmas a class accepts. In VisualWorks a class implements the > <pragma: #pragma:selector:> (it might be <pragmas: #(pragma:selector:one: > pragma:selector:two:)>) to define the legal set of pragmas. > [Implementation note, these are /not/ searched for ahead of compilation; > instead, the parser delays searching for class-side methods containing > pragma: pragmas until it encounters a pragma, and it searches for all class > side methods, including in superclasses). > > > > This scheme allows pragmas to be checked; only pragmas in the set of > allowed pragmas are accepted, and it allows collision-free extensibility; > any package can add a set of legal pragmas to a class merely by choosing a > method selector that won't collide with any other containing pragma: > pragmas, eg > > kernelPragmas > > <pragma: #primitive:> > > <pragma: #primitive:error:> > > <pragma: #primitive:module:> > > <pragma: #primitive:module:error:> > > > > We're missing this, which means our compilers don't safely check for > valid pragmas and can't reject invalid or unrecognized ones, which is error > prone. > > > > If we implemented this then we would have a natural place to comment > pragmas in the method that defines a particular pragma, one that would be > found using senders. > > > > None of this requires a meta object. It is perfectly recursive; using > itself to implement itself. I find this very elegant (I didn't invent > pragma: pragmas; Steve Dahl did, and it's a cool idea). > > > > So as an inventor of pragmas I'd like to ask for the minimal > implementation outlined above. I'd like that we didn't j tricycle a > specific meta object, with all the additional tools that implies, and > instead stick to the minimalist and parsimony of the original design and > use pragmas to comment pragmas. > > > >> Cheers, > >> Doru > > > > Thanks for reading. > > Cheers, Eliot > > > >>> On Jun 27, 2016, at 12:34 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >>> > >>> > >>> 2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >>> Hi, > >>> > >>> That is my proposal as well: introduce a first class entity that > describes a Pragma instance. Who would be interested to play with this? > >>> > >>> How it could be done? > >>> Probably compiler could search preferred Pragma class for given > selector. And then we will have collection of real pragma instances inside > CompiledMethod. What do you think? > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "Be rather willing to give than demanding to get." > >> > >> > >> > >> > >> > > > > -- > www.tudorgirba.com > www.feenk.com > > "When people care, great things can happen." > > > > > > -- _,,,^..^,,,_ best, Eliot

June 27, 2016

Re: [Pharo-dev] Become Identity Forward

by Eliot Miranda

Hi, I don't see the bug. Look at this example: | a b ha hb | a := Object new. b := Object new. ha := a identityHash. hb := b identityHash. a becomeForward: b copyHash: true. { ha = hb. a == b. a identityHash == ha }. #(false true true) So here a has indeed become b; all references to a are now references to b. But b's identityHash is now that of what a's was before the become. That's as specified. Let's extend the example: | a b ha hb is | a := Object new. b := Object new. is := IdentitySet new. *is add: b.* ha := a identityHash. hb := b identityHash. a becomeForward: b copyHash: true. { ha = hb. a == b. a identityHash == ha. *is includes: a* }. #(false true true false) This is correct; a (and b) is (are) now in the set at the old hash of b, which is no longer its hash. So... | a b ha hb is | a := Object new. b := Object new. is := IdentitySet new. is add: b. ha := a identityHash. hb := b identityHash. a becomeForward: b copyHash: true. *is rehash.* { ha = hb. a == b. a identityHash == ha. is includes: a }. #(false true true true) Good. So instead what you might have meant to say was | a b ha hb is | a := Object new. b := Object new. is := IdentitySet new. *is add: a.* ha := a identityHash. hb := b identityHash. a becomeForward: b copyHash: true. { ha = hb. a == b. a identityHash == ha. is includes: a }. #(false true true true) That looks good. On Mon, Jun 27, 2016 at 2:50 AM, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hello, > I'm trying to become forward some objects, these objects are stored > in IdentitySets so I need to copy the identityHash of the older objects to > the new ones. So that the IdentitySets are still well constructed. > > I have read the comments in Array >> elementsForwardIdentityTo: copyHash: > , and Array >> elementsForwardIdentityTo:, so I realise that the operation > I want to use is the first with copyHash in true or the later (that should > be doing the same, from the comments). > > But after trying it, it is not working as expected. > > If I try with: > > x := Object new. > y := Object new. > z := Object new. > > set := IdentitySet new. > set add: x. > set add: y. > > hash := x identityHash. > bhash := x basicIdentityHash. > > self assert:(set isHealthy). > > z becomeForward: x copyHash: true. > > set isHealthy "false" > > z basicIdentityHash = bhash. "false" > z identityHash = hash "false" > > It is not working, but if I changed the copyHash parameter to false, it > works. > > Something is not right (the comment or the implementation), because the > comment says: > > "If copyHash is true, the identityHashes remain with the pointers rather > than with the > objects so that the objects in the receiver should still be properly > indexed in any > existing hashed structures after the mutation. If copyHash is false, then > the hashes > of the objects in otherArray remain unchanged." > > Do I have understanded everything wrong or there is something that is not > working (or at least the comment is not clear) > > Is somebody using these operations? How do you expect to work? > > Maybe If you can help me to understand the situation I can fix the > comments. > > Thanks in advance. > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- _,,,^..^,,,_ best, Eliot

June 27, 2016

Re: [Pharo-dev] [Vm-dev] Re: pharo 5 segfault (stack size?) [FreeBSD]

by Eliot Miranda

Hi Ben, On Sun, Jun 26, 2016 at 6:44 AM, Ben Coman <btc(a)openinworld.com> wrote: > > On Sun, Jun 26, 2016 at 8:37 PM, Petr Fischer <petr.fischer(a)me.com> wrote: > > Yes there is "PharoVMBuilder buildFreeBSD", but some "cog*" errors > occurs... So I am still building with "PharoVMSpur32Builder buildUnix32" > under Linux (CentOS6) and then move compiled vm to my FreeBSD box with > Linux compatibility layer. > > > > I compiled DEBUG vm version according to your advice and this is gdb > output: > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x080aefc1 in scavengeReferentsOf (referrer=684415032) at > /home/pf/pharo/pharo-vm-debug/src/vm/gcc3x-cointerp.c:39014 > > 39014 if (((longAt(referent)) & ((classIndexMask()) - > (isForwardedObjectClassIndexPun()))) == 0) { > > The C files are generated from VMMaker and the line numbers change a > lot. If you look upwards in the C file you should see a generated > comment that links to the Smalltalk source it was generated from. > > > > > I need to learn a little, how to play this "core C" game in gdb... > > What next? > > I recently learnt a bit of using gdb on the image. I'm planning to > write up something but its a few weeks off. The old post How to debug > the VM? [1] by Mariano needs a bit of adaption, but got me off to a > good start. If you look in VMMaker package where #printAllStacks is > defined you'll see some others you can call, that just print the > current Smalltalk call stack. > > [1] https://marianopeck.wordpress.com/2011/04/23/how-to-debug-the-vm/ > > > > > A also compiled PharoS (Pharo Stack) VM, and it's 5x slower, but stable, > there is no stack errors (or other crashes) like in cog spur vm. > > You might also try compiling the VM from upstream sources[2], running > either: > * vm/build.linux32x86/squeak.cog.spur/build.debug/mvm > * vm/build.linux64x64/squeak.cog.spur/build.debug/mvm > > Did you try the early 64-bit Pharo Image [3] suggested by Esteban in > another thread ? > > Also, you might try Squeak 64-bit Image, since its the platform Eliot > develops the VM on, so it is further advanced in 64-bit stability. > That's not true. I develop on Mac OS X using Spur and the 32-bit VM. I do run the 64-bit system from time to time and am currently collaborating with Bob Westergaard to move the Cadence system over to 64-bits. I do hope to use 64-bit Spur from day-to-day but am not there yet, not for any reasons of deficiency in 64-bits but simply because my current, large, project-laden, VMMaker image is in 32-bits and I've not changed it over yet. > Run vm/image/buildspurtrunk64image.sh. > > [2] https://github.com/OpenSmalltalk/vm > [3] http://files.pharo.org/get-files/60/pharo-64.zip > > Now since you are getting down and dirty debugging this at VM level, > probably good to shift this thread to [vm-dev]. > http://lists.squeakfoundation.org/mailman/listinfo/vm-dev > > cheers -ben > > > > > pf > > > > > >> You could build a debug VM from here > >> https://github.com/pharo-project/pharo-vm > >> I also glimpsed some FreeBSD build options there you might try. > >> cheers -ben > >> > >> On Fri, Jun 24, 2016 at 12:05 PM, Petr Fischer <petr.fischer(a)me.com> > wrote: > >> > >> > So... I compiled latest sources (blessed) on CentOS 6.8, fine, moved > >> > compiled binaries to FreeBSD and tried to load Seaside to the latest > 50760 > >> > image. > >> > Still stack errors, log here: http://pastebin.com/raw/bf1EpWNt > >> > > >> > When I run this on CentOS, everything is fine (loading Seaside, no > stack > >> > errors), but when I run the same on FreeBSD, stack errors (segfaults) > >> > occurs. > >> > > >> > So... There is something bad on FreeBSD side? Can I debug more? > >> > > >> > pf > >> > > >> > > >> > > Try 50760 from... > >> > > http://files.pharo.org/image/50/ > >> > > > >> > > cheers -ben > >> > > > >> > > On Sat, Jun 18, 2016 at 12:49 AM, Petr Fischer <petr.fischer(a)me.com > > > >> > wrote: > >> > > > VM version (from > >> > https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/) > >> > > > > >> > > > 5.0 #1 Sun Jan 17 14:19:14 CET 2016 gcc 4.7.2 [Production Spur > ITHB VM] > >> > > > CoInterpreter VMMaker.oscog-eem.1630 uuid: > >> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 > >> > > > StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: > >> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 > >> > > > https://github.com/estebanlm/pharo-vm.git Commit: > >> > 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 > +0100 > >> > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 > >> > > > Linux swing-hudson-lin64 3.2.0-4-amd64 #1 SMP Debian > 3.2.73-2+deb7u2 > >> > x86_64 GNU/Linux > >> > > > plugin path: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin > [default: > >> > /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin/] > >> > > > > >> > > > Image version (from official 5.0 download): > >> > > > > >> > > > [version] 5.0 #50723 > >> > > > > >> > > > pf > >> > > > > >> > > >> in fact, this is not related to FFIâ¦ but it should be fixedâ¦ > >> > > >> > >> > > >> along with the VM version, which version of Pharo are you using? > >> > > >> > >> > > >> Esteban > >> > > >> > >> > > >> > On 17 Jun 2016, at 14:04, Max Leske <maxleske(a)gmail.com> > wrote: > >> > > >> > > >> > > >> > Hi Petr, > >> > > >> > > >> > > >> > That looks like a bug with FreeType with our FFI. It should > >> > actually have been fixed but I donât know if the VM for FreeBSD is up > to > >> > date. Can you post the output of âSmalltalk vm versionâ? > >> > > >> > > >> > > >> > Cheers, > >> > > >> > Max > >> > > >> > > >> > > >> >> On 17 Jun 2016, at 13:26, Petr Fischer <petr.fischer(a)me.com> > >> > wrote: > >> > > >> >> > >> > > >> >> Hello, I got some random segfaults (while loading Seaside) > with 32 > >> > bit spur vm on FreeBSD - can someone (with low level knowledge) decode > >> > attached log? > >> > > >> >> Is this some problem with stack size? Can I fix this? > >> > > >> >> > >> > > >> >> Log: > >> > > >> >> http://pastebin.com/raw/NpFUnjh0 > >> > > >> >> > >> > > >> >> There is "**StackOverflow**" lines n the log... > -- _,,,^..^,,,_ best, Eliot

June 27, 2016

Pharo and Unity

by Paul Davidowitz

It would be fantastic if there were a Pharo SDK for Meta which is powered by Unity (https://www.metavision.com/) Augmented Reality is all about direct interaction -- the very paradigm of Smalltalk itself.

June 27, 2016

[pharo-project/pharo-core]

by GitHub

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

June 27, 2016

[pharo-project/pharo-core] cf23ed: 60120

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: cf23ed03d78cb5c5d68fa043972509e0165602b1 https://github.com/pharo-project/pharo-core/commit/cf23ed03d78cb5c5d68fa043… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-27 (Mon, 27 Jun 2016) Changed paths: M Nautilus.package/AbstractNautilusUI.class/instance/styling/addIconStyle.st A Refactoring-Environment.package/RBClassEnvironment.class/instance/accessing/selectors.st M Refactoring-Tests-Environment.package/RBBrowserEnvironmentTest.class/instance/testing-environments/testClassEnvironment.st A Reflectivity-Tools.package/IconStyler.class/class/api/styleText_withAst_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60119.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60120.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60119.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60120.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/private/installIconStylerFor_.st M System-Announcements.package/SystemAnnouncer.class/definition.st M System-Announcements.package/SystemAnnouncer.class/instance/announce/announce_.st A System-Announcements.package/SystemAnnouncer.class/instance/announce/suspendAllWhileStoring_.st A Tests.package/SystemAnnouncerTest.class/instance/tests/testSuspendAllWhileStoring.st A Tests.package/SystemAnnouncerTest.class/instance/tests/testSuspendAllWhileStoringNested.st Log Message: ----------- 60120 18622 Simplify Iconstyler API https://pharo.fogbugz.com/f/cases/18622 18555 Adding a way of storing the Announcements while suspended https://pharo.fogbugz.com/f/cases/18555 11442 RBClassEnvironment does not respect traits https://pharo.fogbugz.com/f/cases/11442 http://files.pharo.org/image/60/60120.zip

June 27, 2016

[pharo-project/pharo-core] 064aa9: 60119

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 064aa9a42e7eb5516e4500a2ecd384993283c10d https://github.com/pharo-project/pharo-core/commit/064aa9a42e7eb5516e4500a2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-27 (Mon, 27 Jun 2016) Changed paths: M Collections-Strings.package/String.class/class/initialization/initialize.st A Collections-Strings.package/String.class/class/initialization/newAsciiOrder.st A Collections-Strings.package/String.class/class/initialization/newCSLineEnders.st A Collections-Strings.package/String.class/class/initialization/newCaseInsensitiveOrder.st A Collections-Strings.package/String.class/class/initialization/newCaseSensitiveOrder.st A Collections-Strings.package/String.class/class/initialization/newCrLfExchangeTable.st A Collections-Strings.package/String.class/class/initialization/newLowercasingTable.st A Collections-Strings.package/String.class/class/initialization/newTokenish.st A Collections-Strings.package/String.class/class/initialization/newUppercasingTable.st A Collections-Tests.package/StringInitializationTests.class/README.md A Collections-Tests.package/StringInitializationTests.class/definition.st A Collections-Tests.package/StringInitializationTests.class/instance/tests/testAsciiOrder.st A Collections-Tests.package/StringInitializationTests.class/instance/tests/testCSLineEnders.st A Collections-Tests.package/StringInitializationTests.class/instance/tests/testCaseInsensitiveOrder.st A Collections-Tests.package/StringInitializationTests.class/instance/tests/testCrLfExchangeTable.st A Collections-Tests.package/StringInitializationTests.class/instance/tests/testLowercasingTable.st A Collections-Tests.package/StringInitializationTests.class/instance/tests/testTokenish.st A Collections-Tests.package/StringInitializationTests.class/instance/tests/testUppercasingTable.st M ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/symbolic versions/stable_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/versions/versionv3%5F1%5F1_.st A Kernel.package/CompiledMethod.class/instance/accessing/name.st M QualityAssistant.package/QASettings.class/class/settings-definition/qaGroupSettingsOn_.st A Renraku.package/extension/RGMethodDefinition/instance/critiques.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60118.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60119.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60118.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60119.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60119 18627 QualityAssistant v3.1.1 https://pharo.fogbugz.com/f/cases/18627 18609 Add tests for String initialization https://pharo.fogbugz.com/f/cases/18609 18595 CompiledMethod is missing #name methof https://pharo.fogbugz.com/f/cases/18595 http://files.pharo.org/image/60/60119.zip

June 27, 2016

[pharo-project/pharo-core]

by GitHub

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

June 27, 2016

Re: [Pharo-dev] Having comments for pragma?

by Tudor Girba

Hi Eliot, I agree with most things you say (except the conclusion :)), and I think that we are talking about complementary issues. As I mentioned before, there already is a need to distinguish between a plain selector and one that is associated with pragmas. This is what you find in PragmaType in Spotter and Inspector. This is a kind of meta-object and having it adds value. I can search for pragmas âtypeâ (we can also call it a PragmaSelector), and I can distinguish between all occurrences of a pragma âtypeâ and its utilization in computation. But, the current implementation of PragmaType is a mere pseudo-meta-object, given that it has no casual connection to the runtime. What we know from Smalltalk is that the analysis model does not have to differ from the runtime one. The consequence is that every time we do see a difference, we should investigate because we might uncover a hidden need opportunity. I know the VW model, and indeed, we could have something like: MyConcept class>>myPragmaDefinition âa comment about the pragma" <pragma: #selector> However, this only deals with the definition of the pragma type not with the internal representation. There could still well be an object that encapsulates both the selector and the comment. And that object would also allow us to build tools around it. We could call it a PragmaType, PragmaDefinition, or even PragmaSelector. And we could get the Pragma to point to this type either through an inst var or through a query (I would probably prefer an instvar). I think that this proposition does not remove from the simplicity of the implementation at all, but allows the new needs to be accommodated nicely. The alternative is to not do anything, in which case we will continue to have an analysis-only-pseudo-meta-object which is not nice at all. I do not think we should jump on this lightly, but I do think we should have a critical look and evaluate the options. What do you think? Cheers, Doru > On Jun 27, 2016, at 2:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Doru, > >> On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> The CompiledMethod already has a way to retrieve Pragma instances: >> >> CompiledMethod>>pragmas. >> >> However, the Pragma instance does not have a meta-object associated with it. So, I would first start from adding that one and linking such a PragmaType to its instances. The important thing here would be that all Pragma instances with a certain selector should reference the same PragmaType. > > Let me express a dissenting opinion. Our pragma system is minimal yet powerful. By using Message instances (with literal arguments) to represent pragmas we get > - executable pragmas that can be applied using perform: or wrappers such as sentTo: > - we can use conventional browsing queries (implementors and senders) to discover which methods are marked by a specific pragma and what pragma-processing tools implement a specific pragma. > - a rich pragma language that can have many, named parameters > - a system which doesn't need its own language, but reuses the existing Smalltalk parsing facilities, and so is easier to learn and to implement > > So its parsimony is an important part of its virtues. It is minimal. > > One thing missing from the Squeak/Pharo implementation is the set of legal pragmas a class accepts. In VisualWorks a class implements the <pragma: #pragma:selector:> (it might be <pragmas: #(pragma:selector:one: pragma:selector:two:)>) to define the legal set of pragmas. [Implementation note, these are /not/ searched for ahead of compilation; instead, the parser delays searching for class-side methods containing pragma: pragmas until it encounters a pragma, and it searches for all class side methods, including in superclasses). > > This scheme allows pragmas to be checked; only pragmas in the set of allowed pragmas are accepted, and it allows collision-free extensibility; any package can add a set of legal pragmas to a class merely by choosing a method selector that won't collide with any other containing pragma: pragmas, eg > kernelPragmas > <pragma: #primitive:> > <pragma: #primitive:error:> > <pragma: #primitive:module:> > <pragma: #primitive:module:error:> > > We're missing this, which means our compilers don't safely check for valid pragmas and can't reject invalid or unrecognized ones, which is error prone. > > If we implemented this then we would have a natural place to comment pragmas in the method that defines a particular pragma, one that would be found using senders. > > None of this requires a meta object. It is perfectly recursive; using itself to implement itself. I find this very elegant (I didn't invent pragma: pragmas; Steve Dahl did, and it's a cool idea). > > So as an inventor of pragmas I'd like to ask for the minimal implementation outlined above. I'd like that we didn't j tricycle a specific meta object, with all the additional tools that implies, and instead stick to the minimalist and parsimony of the original design and use pragmas to comment pragmas. > >> Cheers, >> Doru > > Thanks for reading. > Cheers, Eliot > >>> On Jun 27, 2016, at 12:34 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> >>> 2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> Hi, >>> >>> That is my proposal as well: introduce a first class entity that describes a Pragma instance. Who would be interested to play with this? >>> >>> How it could be done? >>> Probably compiler could search preferred Pragma class for given selector. And then we will have collection of real pragma instances inside CompiledMethod. What do you think? >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> >> > -- www.tudorgirba.com www.feenk.com "When people care, great things can happen."

June 27, 2016