March 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Specifying library dependencies in UFFI

by Ben Coman

On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch> wrote: > Hi Ben, > > my understanding is that SetDllDirectory only affects the search path of > libraries that are loaded at *run-time* with LoadLibrary. > > What I'm asking for is a mechanism that works at *load-time*, when a > library I'm accessing directly depends on another one which I'm not > targeting directly. > I don't quite follow. I'm not intimate with Windows dynamic loading, so these questions are an opportunity for me to learn... You can't mean when Pharo loads, because it wouldn't know of OTHER.DLL ? Do you mean that LoadLibrary is not called explicitly by YOUR.DLL before its uses the function from OTHER.DLL? Do you mean you link OTHER.DLL to YOUR.DLL at compile time? But still, YOUR.DLL it not loaded until called via Pharo FFI, so neither is OTHER.DLL, and Dynamic-Link Library Search Order [1] says... "If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL." So maybe before calling any of YOUR.DLL, do a SetDllDirectory followed by a LoadLibrary(OTHER.DLL) and later when you call into YOUR.DLL, OTHER.DLL is already loaded. Otherwise it would seems(?) your options are either Manifests or Dynamic-Link Library Redirection, both done outside of Pharo. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).… cheers -ben > But I'll try whether SetDllDirectory also affects load-time searches. > > Anyway, I hope future versions of the UFFI to offer setting the search > paths more easily. > > > > Greetings > Raffaello > > > > On 2017-03-15 07:22, Ben Coman wrote: > >> >> >> On Tue, Mar 14, 2017 at 11:23 PM, Raffaello Giulietti >> <raffaello.giulietti(a)lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch>> wrote: >> >> Hi, >> >> say I want to directly use a library that depends on other libraries >> in different folders. How does UFFI proceed to find these other >> libraries? >> >> Is there a way to specify the search folders in UFFI? >> >> I'm on Windows and in Pharo5/6. >> >> Greetings >> Raffaello >> >> >> I assume you mean specifying the search path outside of Pharo. >> Perhaps call SetDllDirectory via Pharo FFI. >> (YMMV disclaimer, my knowledge of this is a few minutes searching) >> >> SetDllDirectory function >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms6 >> 86203(v=vs.85).aspx >> >> LoadLibrary function >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms6 >> 84175(v=vs.85).aspx >> >> Dynamic-Link Library Search Order >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms6 >> 82586(v=vs.85).aspx >> >> cheers -ben >> > > >

March 15, 2017

Re: [Pharo-users] programmatic use of the language compiler

by denker

> On 14 Mar 2017, at 11:23, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: > > Hi, > > I'm wondering how to programmatically compile a method. I tried using a variant of > ClassDescription>>compile:*:notifying: Yes, this is the Smalltalk API. You can use the compiler directly and then install the method yourself, too. The compiler has a number of setters and then a build method (#compile if you are interested in a compiled method). OpalCompiler new class: Object; source: âfoo ^1â; compile. or, if you compile for a class the class can give a pre-setup compiler: Object compiler source: 'foo ^1'; compile. then you can install the method with addSelector:withMethod: > However, on a method with undeclared variables, when the Transcript is open there seems to be no way to avoid a message being written there. Further, the requestor passed as a notifier in the above method is not even notified when the compilation context is not interactive. > Yes, this is sadly right now hard-codedâ¦ but in the Exception. So you can do what the exception does yourself: method := [Object compiler source: 'foo ^a'; compile] on: OCUndeclaredVariableWarning do: [ :ex | | varName | varName := (ex instVarNamed: #node) name. Undeclared at: varName asSymbol put: nil. ex resume: (OCUndeclaredVariable new name: varName asSymbol). ]. > What is the correct way to use the compiler programmatically and in a non interactive batch, still being able to catch all the compilation errors and warnings? What we need for the future is to have not just logging but real compiler error objectsâ¦ there are other cases where it would be nice (e.g. to get a list of all errors after loading a package with monticello). We should improve the compiler for Pharo7â¦ Marcus

March 15, 2017

Re: [Pharo-users] MetaLinks with arbitrary number of arguments

by denker

> On 15 Mar 2017, at 11:09, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > On Wed, Mar 15, 2017 at 10:49:51AM +0100, denker wrote: >> >>> On 15 Mar 2017, at 10:35, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>> Hi, >>> >>> is it possible to create a metalink on arbitrary amount of arguments? >>> >>> Right now the metaObject and selector must have the same number of arguments, e.g. >>> >>> MetaLink new >>> metaObject: [ :object :selector :args | ... ]; >>> selector: #value:value:value; >>> arguments: #(object selector arguments) >>> >>> >>> What I would like to have instead is something like... >>> >>> MetaLink new >>> metaObject: [ :allArgs | ... ]; >>> selector: #value:; >>> arguments: #(object selector arguments) >>> >>> >>> And then `allArgs` would either be an array with all the arguments, or maybe a Dictionary. >>> >> >> Right now notâ¦ but it would be a nice addition. >> >> It could either use some magic (if the number of args requested are larger then the number of args >> of the selector it gives the rest as a dictionary). >> >> or, maybe better (less magic), this could be an option to be configured per link: >> >> >> MetaLink new >> metaObject: [ :allArgs | ... ]; >> selector: #value:; >> arguments: #(object selector arguments) >> options: #(argsAsDictionary) >> >> (which would allow #argsAsArray, too). >> >> Marcus > > > +1 for option, magic only brings suffering. :) > This should be easy.. I will look into it hopefully this week. Marcus

March 15, 2017

[ANN] Collecting all Pharo related publications

by Marcus Denker

Hi, We want to create a list of all Pharo related papers. I have added this page: http://pharo.org/web/PharoPublications <http://pharo.org/web/PharoPublications> it is linked from http://pharo.org/documentation <http://pharo.org/documentation> Marcus

March 15, 2017

Re: [Pharo-users] MetaLinks with arbitrary number of arguments

by Peter Uhnak

On Wed, Mar 15, 2017 at 10:49:51AM +0100, denker wrote: > > > On 15 Mar 2017, at 10:35, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > is it possible to create a metalink on arbitrary amount of arguments? > > > > Right now the metaObject and selector must have the same number of arguments, e.g. > > > > MetaLink new > > metaObject: [ :object :selector :args | ... ]; > > selector: #value:value:value; > > arguments: #(object selector arguments) > > > > > > What I would like to have instead is something like... > > > > MetaLink new > > metaObject: [ :allArgs | ... ]; > > selector: #value:; > > arguments: #(object selector arguments) > > > > > > And then `allArgs` would either be an array with all the arguments, or maybe a Dictionary. > > > > Right now notâ¦ but it would be a nice addition. > > It could either use some magic (if the number of args requested are larger then the number of args > of the selector it gives the rest as a dictionary). > > or, maybe better (less magic), this could be an option to be configured per link: > > > MetaLink new > metaObject: [ :allArgs | ... ]; > selector: #value:; > arguments: #(object selector arguments) > options: #(argsAsDictionary) > > (which would allow #argsAsArray, too). > > Marcus +1 for option, magic only brings suffering. :) Peter

March 15, 2017

Re: [Pharo-users] MetaLinks with arbitrary number of arguments

by denker

> On 15 Mar 2017, at 10:35, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > is it possible to create a metalink on arbitrary amount of arguments? > > Right now the metaObject and selector must have the same number of arguments, e.g. > > MetaLink new > metaObject: [ :object :selector :args | ... ]; > selector: #value:value:value; > arguments: #(object selector arguments) > > > What I would like to have instead is something like... > > MetaLink new > metaObject: [ :allArgs | ... ]; > selector: #value:; > arguments: #(object selector arguments) > > > And then `allArgs` would either be an array with all the arguments, or maybe a Dictionary. > Right now notâ¦ but it would be a nice addition. It could either use some magic (if the number of args requested are larger then the number of args of the selector it gives the rest as a dictionary). or, maybe better (less magic), this could be an option to be configured per link: MetaLink new metaObject: [ :allArgs | ... ]; selector: #value:; arguments: #(object selector arguments) options: #(argsAsDictionary) (which would allow #argsAsArray, too). Marcus

March 15, 2017

MetaLinks with arbitrary number of arguments

by Peter Uhnak

Hi, is it possible to create a metalink on arbitrary amount of arguments? Right now the metaObject and selector must have the same number of arguments, e.g. MetaLink new metaObject: [ :object :selector :args | ... ]; selector: #value:value:value; arguments: #(object selector arguments) What I would like to have instead is something like... MetaLink new metaObject: [ :allArgs | ... ]; selector: #value:; arguments: #(object selector arguments) And then `allArgs` would either be an array with all the arguments, or maybe a Dictionary. Thanks, Peter

March 15, 2017

Re: [Pharo-users] Specifying library dependencies in UFFI

by Raffaello Giulietti

Hi Ben, my understanding is that SetDllDirectory only affects the search path of libraries that are loaded at *run-time* with LoadLibrary. What I'm asking for is a mechanism that works at *load-time*, when a library I'm accessing directly depends on another one which I'm not targeting directly. But I'll try whether SetDllDirectory also affects load-time searches. Anyway, I hope future versions of the UFFI to offer setting the search paths more easily. Greetings Raffaello On 2017-03-15 07:22, Ben Coman wrote: > > > On Tue, Mar 14, 2017 at 11:23 PM, Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>> wrote: > > Hi, > > say I want to directly use a library that depends on other libraries > in different folders. How does UFFI proceed to find these other > libraries? > > Is there a way to specify the search folders in UFFI? > > I'm on Windows and in Pharo5/6. > > Greetings > Raffaello > > > I assume you mean specifying the search path outside of Pharo. > Perhaps call SetDllDirectory via Pharo FFI. > (YMMV disclaimer, my knowledge of this is a few minutes searching) > > SetDllDirectory function > https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203(v=vs.85).… > > LoadLibrary function > https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).… > > Dynamic-Link Library Search Order > https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).… > > cheers -ben

March 15, 2017

Re: [Pharo-users] Specifying library dependencies in UFFI

by Raffaello Giulietti

Hi Phil, I'm familiar with all this, but it doesn't help. Suppose my code directly accesses "my.dll" which, in turn, depends on "her.dll" which my code does not need directly and suppose that library is located in folder "<path-to-her-folder>". How can I enforce the UFFI to perform the search there? BTW, the URI you mention is not reachable. I usually use the following: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… On 2017-03-15 00:13, phil(a)highoctane.be wrote: > > Yes there is. Search for the .so or .dll or .dylib strings with the > finder and you will see a few and how they are found. > > Also check > https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… > where there are examples like > > Let's for example consider the library LibC already provided by uFFI: > > FFILibrary subclass: #LibC > instanceVariableNames: '' > classVariableNames: '' > package: 'UnifiedFFI-Libraries' > > LibC>>macModuleName > ^ 'libc.dylib' > > LibC>>unixModuleName > ^ 'libc.so.6' > > LibC>>win32ModuleName > "While this is not a 'libc' properly, msvcrt has the functions we are > defining here" > ^ 'msvcrt.dll' > > This is for libraries that are in the path or library path. > > One can come up with other strategies for loading these, with absolute > path like '/usr/lib/xxx.so' > > Beware of the 32/64 bit thing< 32 bit pharo needs 32 bit lib. > > I am using a 32 bits container on linux to build 32 bits libraries, much > less headaches. > > See https://gist.github.com/philippeback/33717128d5fb24263e557922d5ac913e > > HTH > > > Phil

March 15, 2017

Re: [Pharo-users] New Version of Pillar on Windows

by stepharong

Oki You see I cannot compile the latest version of Entreprise Pharo on my machine. One day I will go back to it. Stef > > Hello Steph, > > > Thank you and those that helped me on both Slack and Discord. This > turned out to be an obsolescence issue! Mine and the April 2016 edition > of Enterprise Pharo which I was >using!!! Once I was pointed in the > right direction, to the most recent edition of the book, everything I > needed was thereâ¦ Donât you just love newbiesâ¦ :>} . > > You all have created a great learning environment and resources, not to > mention evolving the most pleasant rendition of the SmallTalk > environment Iâve ever seen. Thank you. > > > Mike > p.s. (post script): âYou allâ is the Southern U.S. English plural of > âyouâ for those who havenât heard it before. Donât adopt it though, it > is only a dialect ;>}. > > > Hi mike > > > Was it working before? > > I will check on the HTML case (now) because I'm checked the mooc and the > book. > > >> I am trying out the new version of Pillar (build 1940 or 1941) on > >> Windows on Pharo 50770, following the Pillar tutorial in Enterprise > >> Pharo book: > >> I created the new file first.pillar containing: ! Hello World > >> > >> I ran: C:\Users\mldavis\Desktop\mldPillarWorking>Pharo.exe > >> Pillar.image pillar export --to=html first.pillar > >> > >> It created a file named: output.html.json containing: > >> {"content":"<section>\r\n<h1>1. Hello World</h1>\r\n</section>"} > > this is correct. > > It looks like the mustache phase is not applied. > >> > >> It was supposed to be an HTML document as shown in Enterprise Pharo > >> para > >> 14.2 page 213 "5 Minutes Tutorial". > >> > >> Any suggestions what I missed or should do? > > Normally the makefile should invoke mustache to apply a template with as > input such file > >> > >> mike > >> > >> -- Using Opera's mail client: http://www.opera.com/mail/

March 15, 2017