Tx phil for these cool words.
We are pushing and we need inputs too because from time to time I have the
impression that we
are focusing a bit too much on our own system but this is natural :)
Stef
On Fri, 17 Mar 2017 07:17:38 +0100, p...@highoctane.be
wrote:
It is true that you can ki
Not that well on macOS.
Yes it works but you want to launch Pharo from thr Dock and not via the
command line.
But yes put the DLLs in with the VM files should work in all main OSs
Mark
On 17/03/2017 08:44,
raffaello.giulie...@lifeware.ch wrote:
Hi Pierce,
sure, this works on any Unix-like
Hi Pierce,
sure, this works on any Unix-like system.
On 17/03/17 03:37, Pierce Ng wrote:
> On Wed, Mar 15, 2017 at 09:31:45AM +0100, Raffaello Giulietti wrote:
>> Suppose my code directly accesses "my.dll" which, in turn, depends
>> on "her.dll" which my code does not need directly and suppose
It is true that you can kill an image or two doing this.
A reason why I added this little thing
https://github.com/Pharophile/HOImageSaver and use it quite often.
I also got a debug and assert VM to build for Windows, so I have the full
symbols table available.
Running Pharo and, say CodeBlocks
On Wed, Mar 15, 2017 at 09:31:45AM +0100, Raffaello Giulietti wrote:
> 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 "". How can I
> enforce the UFFI to perform the search there?
A utility to view DLLs is this one
http://www.nirsoft.net/utils/dll_export_viewer.html
It helped a lot in my project.
also C compilers have several checks for DLL loading
Visual studio also has several tools for low level detection of memory if
you are familiar with Assembly it has also disasse
In general I would agree do in C or C++ to cut down the interface and
pass as little data between the two languages as possible. So hiding of
C++ objects and exceptions and the others listed in you last paragraph
is reasonable
However the OS functions for loading need to be controlled outside
Hi Dimitris,
I think I understand what you mean.
You are probably saying that, when facing multiple libraries that need
to be glued together, it is far better to implement a C "gluing" library
and then targeting that one from the UFFI rather than trying to do the
gluing code using Smalltalk and t
My point was that anything you do in Pharo will lower performance quite a
bit, but it wont be noticable anyway unless its in a big loop or something.
Second that Pharo cannot debug such issues which is a huge deal when you
work with OS stuff and OS calls.
You are far better doing this outside UFF
Indeed, experimenting using some combination of AddDllDirectory(),
SetDllDirectory() and LoadLibraryEx() was in my plan for next week.
Thanks
On 16/03/17 11:59, Mark Bestley wrote:
> Yes the calling process can alter where these indirect DLLs are loaded
> from and so should be able to be done i
Yes the calling process can alter where these indirect DLLs are loaded
from and so should be able to be done in UFFI and directly from Smalltalk
The OS will load the DLL specified then it runs DllMain and doing that
causes the OS to load any DLLs that it calls
MSDN https://msdn.microsoft.com/
Hi Dimitris,
I don't get your point about proper C coding, C performance or Pharo
crashes. It is not the focus of this thread.
How dependencies between libraries are resolved at load-time is dictated
by the OS. If the OS offers a working mechanism to specify folders that
the OS uses to searc
Please note the moment you use a FFI of any language you step to a C
territory. VMs tend not to touch the code because the code is already in
machine code format.
There is zero reason for UFFI to worry about the dependencies of a library
loaded, this must happen at the library level that UFFI does
> On 15 Mar 2017, at 15:44, Raffaello Giulietti
> wrote:
>
> On 2017-03-15 15:20, Esteban Lorenzano wrote:
>>
>>> On 15 Mar 2017, at 15:08, Raffaello Giulietti
>>> wrote:
>>>
>>> Hi Esteban,
>>>
>>> I understand this is the current status of the UFFI, so I can certainly use
>>> the workar
On 2017-03-15 15:20, Esteban Lorenzano wrote:
On 15 Mar 2017, at 15:08, Raffaello Giulietti
wrote:
Hi Esteban,
I understand this is the current status of the UFFI, so I can certainly use the
workarounds discussed below.
But I hope UFFI will soon offer a more "declarative" way to specify t
> On 15 Mar 2017, at 15:08, Raffaello Giulietti
> wrote:
>
> Hi Esteban,
>
> I understand this is the current status of the UFFI, so I can certainly use
> the workarounds discussed below.
>
> But I hope UFFI will soon offer a more "declarative" way to specify the
> search folders, kind of L
Hi Esteban,
I understand this is the current status of the UFFI, so I can certainly
use the workarounds discussed below.
But I hope UFFI will soon offer a more "declarative" way to specify the
search folders, kind of LD_LIBRARY_PATH mechanism but in the UFFI.
Greetings
Raffaello
On 20
Hi,
UFFI cannot do what you want.
If I understand well, you have:
Pharo -> libA.dll -> libB.dll
Pharo does a LoadLibrary(libA.dll), but has no control on how libA calls libB…
and is not possible for us to influence it more than the predefined platform
ways.
One posible workaround (just po
On 2017-03-15 13:51, Ben Coman wrote:
On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti
mailto:raffaello.giulie...@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.
On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti <
raffaello.giulie...@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 *lo
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 direct
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 "". How can I enforce the UFFI
to perform the search there?
BTW, the
On Tue, Mar 14, 2017 at 11:23 PM, Raffaello Giulietti <
raffaello.giulie...@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 folde
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/PharoBookWorkInProgresshttps://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSucces
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
25 matches
Mail list logo
