Re: [Pharo-users] MetaLinks for Dynamic Contracts
> On 3 May 2020, at 23:18, Evan Donahue wrote: > > Hello, > > I am returning to some work in Pharo after about ~2.5 years and reminding > myself of what I was working on before I got sidetracked. It appears > > I had mostly finished for release a dynamic contracts library for run time > type checking based on Racket's contract library.[1] However, it relied on > some hackery to interact well with the TestCoverage class, since both the > contract and the TestCoverage wanted to replace the method during the run of > a test. However, since it seems in Pharo 8 the TestCoverage class is no > longer present, this seems like a good time to re-evaluate the project before > I go in to see what needs to be patched up. I therefore have three questions: > > 1) Are there now any existing libraries for dynamic contracts that I should > use instead of patching my old library? > > 2) Is MetaLinks the preferred way to intercept messages, and if so can > someone point me to the repo (I can't seem to find it on Github)? > The MetaLinks are in the release, no need to load anything. > 3) If 2, does MetaLinks play well with whatever is the current TestCoverage > alternative that I assume still does some form of message interception, e.g. > will the test coverage function still work properly on a MetaLink'ed message, > or will that require further hackery (I discovered MetaLinks after the first > version, so I used the more basic message replacement apis)? > The test Coverage was re-implemented with MataLink, see the method #collectCoverageFor: in TestRunner. This means that it should compose nicely with any other #before or #after MetaLink, without any need to take special care. Marcus
Re: [Pharo-users] FFI and absolute path to dll
On Sun, 17 May 2020 at 20:54, ASAM wrote: > Thanks for the tips. It really helped me a lot. > The dll is now loaded (I chose the 64-bit version of the dll). > > I am currently working on value mashalling and I want to create an ENUM > class subclass from FFIEnumeration. > > Inside http://books.pharo.org/booklet-uffi/pdf/2020-02-12-uFFI-V1.0.1 i > read chapter 4.4 Enumerations. > I tried the example. > For me, however, only new class variables are created after > "ExampleEnumeration initialize". > > Is that okay? or a bug? > The class-side #initialization method only gets called when the class is created e.g. when first loaded into a fresh image. It doesn't get re-run just because you edit the method, because the class is already initialized. By analogy, evaluating ``x := MyObject new`` invokes the instance-side initialize when the object is created. Subsequently editing MyObject >> #initialize wont change any values in the existing object in `x`. Remember "classes are objects too". cheers -ben
Re: [Pharo-users] FFI and absolute path to dll
> On 18 May 2020, at 19:12, Ben Coman wrote: > > The class-side #initialization method only gets called when the class is > created e.g. when first loaded into a fresh image. Almost: it gets to run whenever the method is loaded and is new or different. If the method is loaded again and its source code is the same, it does not run.
[Pharo-users] [ANN] Smalltalkhub Readonly Migration tuesday 8hs - server maintenance / migration
Hi all, We wanted to announce that, as announced previously, Smalltalkhub is going read only from tomorrow, 8h central Europe time. This means the service could be down for a couple of hours until the sync of data is done. Keep tuned, Guille and Christophe in behalf of the RMoD team
Re: [Pharo-users] FFI and absolute path to dll
Oh. Thank you for your answers. Now that you say it, I remember it. I dealt with Pharo 2 years ago. And now I come back to load and execute a DLL with Pharo. Does anyone have a more detailed example of FFIOpaqueObjectis object than in the book (http://books.pharo.org/booklet-uffi/pdf/2020-02-12-uFFI-V1.0.1) ? I don't really understand it yet. I want to call a DLL whose API has 33 functions, 41 structures and 15 enums. I would like to do it right and I have to understand everything first so that I can then decide how to implement it. Thank you for your help -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] [ANN] What are good reasons to use Smalltalk?
It's 2020 and we're still faced with browser compatibility issues?!! Man, the web is really a piece o' sh*t. Offray Vladimir Luna Cárdenas-2 wrote > Same for Firefox. I thought the poll was closed when I visited. Now I > can check it works on Chromium. I wonder how many people tried to > participate before but has not the proper browser to do it and not even > a clue about that. > > How could be this pull be made more open and accessible? > > Cheers, > > Offray > > On 15/05/20 4:35 p. m., Esteban Maringolo wrote: >> I don't know what is behind the poll system, but it doesn't work in >> Brave browser. It simply says "Thanks for participating in the poll." >> >> I find the questions confusing though. >> >> Esteban A. Maringolo >> >> On Wed, May 13, 2020 at 4:43 PM Richard Kenneth Eng >> < > horrido.hobbies@ > > wrote: >>> https://smalltalk.tech.blog/2020/05/13/what-are-good-reasons-to-use-smalltalk/ >>> >>> Please participate in the poll. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
[Pharo-users] Cant add local git repo to Iceberg
--- Begin Message --- I already have a GitHub repository named FredsLunch-Pharo. The local clone of that (using shell and git) is Importing repository from /Users/Michael/Development/gitRepos/FredsLunch-Pharo > [graphe:~/Development/gitRepos/FredsLunch-Pharo] Michael% git status > On branch master > Your branch is up-to-date with 'origin/master'. > Changes to be committed: > (use "git reset HEAD ..." to unstage) > > modified: FredsLunch.st > new file: FredsLunchCSV.st > new file: FredsLunchLunch.st > new file: FredsLunchLunchData.st > new file: FredsLunchLunchList.st > new file: FredsLunchMain.st > new file: FredsLunchMember.st > new file: FredsLunchMemberList.st > new file: FredsLunchParticipant.st > new file: FredsLunchTest.st > modified: FredsLunchTests.st > new file: ManifestFredsLunch.st > > Untracked files: > (use "git add ..." to include in what will be committed) > > pharo-local/ > > [graphe:~/Development/gitRepos/FredsLunch-Pharo] Michael% pwd > /Users/Michael/Development/gitRepos/FredsLunch-Pharo > [graphe:~/Development/gitRepos/FredsLunch-Pharo] Michael% > The files currently in that repo were the result of doing a fileOut of each of the classes in the package. Now, I’m trying to register that local repository in Iceberg. After I supply the pathname for the repository and press OK I get an exception window. Copy stack from debug window: > FFICallout>>loaderForArgNamed: > FFICallout>>loaderForArgNamed:indirectIndex: > FFIVariableArgument>>resolveUsing: > [ :arg2 | arg2 resolveUsing: arg1 ] in FFIFunctionSpec>>resolveUsing: in > Block: [ :arg2 | arg2 resolveUsing: arg1 ] > OrderedCollection>>do: > FFIFunctionSpec>>resolveUsing: > FFICalloutMethodBuilder>>generateMethodFromSpec: > FFICalloutMethodBuilder>>generate > FFICalloutMethodBuilder>>build: > FFICalloutAPI>>function:library: > FFICalloutAPI>>function:module: > LGitRepository(LGitExternalObject)>>callUnchecked:options: > LGitRepository>>repository_open:bare_path: > [ self > repository_open: self > bare_path: self repositoryReference pathString ] in LGitRepository>>open in > Block: [ self... > LGitRepository(LGitExternalObject)>>withReturnHandlerDo: > LGitRepository>>open > IceLibgitRepository>>repositoryHandle > [ | tmp1 | > self isValid > ifFalse: [ ^ #() ]. > tmp1 := self repositoryHandle allRemotes. > ^ tmp1 > collect: [ :arg1 | > | tmp3 | > tmp3 := IceGitRemote name: arg1 remoteName url: arg1 url. > tmp3 > localRepository: self; > yourself ] ] in IceLibgitRepository>>remotes in Block: [ | tmp1 |... > BlockClosure>>on:do: > IceLibgitRepository>>handleLibgitError: > IceLibgitRepository>>remotes > IcePharoPlugin class>>isAvailableFor: > [ :arg2 | arg2 isAvailableFor: arg1 ] in IcePlugin class>>allAvailableFor: in > Block: [ :arg2 | arg2 isAvailableFor: arg1 ] > OrderedCollection>>select: > IcePlugin class>>allAvailableFor: > IcePluginManager>>availablePluginsFor: > IcePluginManager>>initializeRepository: > IcePluginManager class>>managerFor: > IceLibgitRepository(IceRepository)>>pluginManager > IceRepositoryCreator>>addLocalRepository > > If I try to Fuel out the exception I get another exception whose stack looks like this: > File>>openForWrite: > File>>openForWrite > File>>writeStream > File>>writeStreamDo: > FLPharo7Platform>>fileNamed:writeStreamDo: > FLSerializer>>serialize:toFileNamed: > FuelOutStackDebugAction class>>serializeTestFailureContext:toFileNamed: > FuelOutStackDebugAction>>serializeStack > FuelOutStackDebugAction>>executeAction > FuelOutStackDebugAction(DebugAction)>>execute > [ self execute ] in FuelOutStackDebugAction(DebugAction)>>asGlamourAction in > Block: [ self execute ] > BlockClosure>>glamourValueWithArgs: > GLMGenericAction(GLMAction)>>actOn: > GLMGenericAction(GLMAction)>>morphicActOn: > [ | tmp2 | > (tmp2 := selector numArgs) = 0 > ifTrue: [ target perform: selector ] > ifFalse: [ tmp2 = arguments size > ifTrue: [ target perform: selector withArguments: > arguments ] > ifFalse: [ target perform: selector withArguments: > (arguments copyWith: arg1) ] ]. > self > showShortcut; > changed ] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in > Block: [ | tmp2 |... > BlockClosure>>ensure: > CursorWithMask(Cursor)>>showWhile: > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: > MouseButtonEvent>>sentTo: > ToggleMenuItemMorph(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>handleMouseUp: > MouseButtonEvent>>sentTo: > [ ^ arg1 sentTo: self ] in MorphicEventDispatcher>>dispatchEvent:with: in > Block: [ ^ arg1 sentTo: self ] > BlockClosure>>ensure: > MorphicEventDispatcher>>dispatchEvent:with: > ToggleMenuItemMorph(Morph)>>processEvent:using: > MorphicEventDispatc
Re: [Pharo-users] [ANN] What are good reasons to use Smalltalk?
On Mon, May 18, 2020 at 4:01 PM horrido wrote: > It's 2020 and we're still faced with browser compatibility issues?!! > > Man, the web is really a piece o' sh*t. > Ah, you forgot the little detail about having to authorize 3-4 dozen(!) scripts from many different sources to run on your computer before the site is remotely usable. And, then you get to their programmers' definition of usable. > > > Offray Vladimir Luna Cárdenas-2 wrote > > Same for Firefox. I thought the poll was closed when I visited. Now I > > can check it works on Chromium. I wonder how many people tried to > > participate before but has not the proper browser to do it and not even > > a clue about that. > > > > How could be this pull be made more open and accessible? > > > > Cheers, > > > > Offray > > > > On 15/05/20 4:35 p. m., Esteban Maringolo wrote: > >> I don't know what is behind the poll system, but it doesn't work in > >> Brave browser. It simply says "Thanks for participating in the poll." > >> > >> I find the questions confusing though. > >> > >> Esteban A. Maringolo > >> > >> On Wed, May 13, 2020 at 4:43 PM Richard Kenneth Eng > >> < > > > horrido.hobbies@ > > > > wrote: > >>> > https://smalltalk.tech.blog/2020/05/13/what-are-good-reasons-to-use-smalltalk/ > >>> > >>> Please participate in the poll. > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >
