[Pharo-users] Magritte extension

2017-03-16 Thread Asbath Sama biyalou via Pharo-users
--- Begin Message --- Hello. I am using Magritte to generate reports for a pharo class. I want to customize generated components in order to have a better design. My class is Match Object subclass: #Match instanceVariableNames: 'date_match hour_match status actions stadium comments teams goa

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

2017-03-16 Thread p...@highoctane.be
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

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

2017-03-16 Thread Pierce Ng
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?

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

2017-03-16 Thread Dimitris Chloupis
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

Re: [Pharo-users] doesNotUnderstand: infinit loop

2017-03-16 Thread Esteban A. Maringolo
I got used to save the image before debugging a single test and/or recover lost changes. But this is certainly hard if you want to do TDD :) Is this related with the debugger UI (GT) or with the underlying frameworks? Regards, -- Esteban El mar. 16, 2017 12:37 PM, "Denis Kudriashov" escribió:

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

2017-03-16 Thread Mark Bestley
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

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

2017-03-16 Thread raffaello . giulietti
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

Re: [Pharo-users] doesNotUnderstand: infinit loop

2017-03-16 Thread Denis Kudriashov
And it works in Squeak 2017-03-16 16:56 GMT+01:00 Denis Kudriashov : > I opened issue 19848 > > > 2017-03-16 16:36 GMT+01:00 Denis Kudriashov : > >> That is sad. It work

Re: [Pharo-users] doesNotUnderstand: infinit loop

2017-03-16 Thread Denis Kudriashov
I opened issue 19848 2017-03-16 16:36 GMT+01:00 Denis Kudriashov : > That is sad. It works from workspace but not during debugging tests. > > 2017-03-16 15:11 GMT+01:00

Re: [Pharo-users] doesNotUnderstand: infinit loop

2017-03-16 Thread Denis Kudriashov
That is sad. It works from workspace but not during debugging tests. 2017-03-16 15:11 GMT+01:00 Esteban A. Maringolo : > Was this fixed? > > I'm debugging unit tests and I'm getting an infinte loop everytime a > MNU is triggered. > > MessageNotUnderstood: receiver of "new" is nil > UndefinedObjec

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

2017-03-16 Thread Dimitris Chloupis
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

Re: [Pharo-users] doesNotUnderstand: infinit loop

2017-03-16 Thread Esteban A. Maringolo
Was this fixed? I'm debugging unit tests and I'm getting an infinte loop everytime a MNU is triggered. MessageNotUnderstood: receiver of "new" is nil UndefinedObject(Object)>>doesNotUnderstand: #new Message>>sentTo: UndefinedObject(Object)>>doesNotUnderstand: #new Message>>sentTo: VM: Unix built

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

2017-03-16 Thread raffaello . giulietti
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

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

2017-03-16 Thread Mark Bestley
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/

Re: [Pharo-users] iceberg

2017-03-16 Thread Damien Pollet
+1 (for some big value of one) On 16 March 2017 at 11:42, Norbert Hartl wrote: > Sometimes tools change and you feel the change like a quantum leap. For me > it is the case when using iceberg. > > Well done, thank you very much for that. > > If Versionner would be able to edit baselines we would

[Pharo-users] iceberg

2017-03-16 Thread Norbert Hartl
Sometimes tools change and you feel the change like a quantum leap. For me it is the case when using iceberg. Well done, thank you very much for that. If Versionner would be able to edit baselines we would have a really rich workflow for developing. Norbert

Re: [Pharo-users] snap package can't find vm-display-X11

2017-03-16 Thread Alistair Grant
On 14 March 2017 at 08:50, Alistair Grant wrote: > On 13 March 2017 at 17:43, Alistair Grant wrote: >> Hi Guillermo, >> ... >> >> Cairo isn't working yet. It looks like CairoLibrary makes assumptions >> about the location of libcairo.so. I'm in the middle of fixing that >> at the moment. > > I'