Re: [Pharo-users] UFFI with asynchronous callbacks

2017-11-08 Thread Todd Blanchard
Just catching up

I'm trying to work with 64 bit Pharo 6.(1? 2?).

I've run into some issues that I have not been able to resolve.  I've loaded up 
TalkFFI with the LibClang library and testLocation fails.  Anything that tries 
to deal with getting a code location fails and I cannot figure out what the 
issue is yet.

Also, callbacks do not work at all.  

One might say that this is only tested on 32 bit Pharo and that's fine, but I 
have a 64 bit computer loaded with 64 bit standard libraries and recompiling 
everything to get 32 bit versions is just not practical.  Its past time to do 
the 64 bit thing.

FWIW, my test library at this point is SQLite Amalgam header to see if I can 
automatically build a SQLite interface (should be easy as it is one file) but 
it is kind of frustrating that these libclang features are not working on 64 
bit libs.  

I have been running in lldb to try to catch the crashes, and I have written a 
number of toy programs to make certain things are the sizes I expect.

Still stuck at this juncture.

Had to take a lil break and learn to program a Particle board for a work 
project but will resume next week.


> On Oct 23, 2017, at 11:13 AM, Ben Coman  wrote:
> 
> 
> 
> On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada  > wrote:
> Hi,
> 
> I would like to connect fingerprint reader to pharo - so far I am able to use 
> C library to connect to it using UFFI,
> however the problem is that I can wait for fingerprint indefinitely ( 
> blocking call to library) or register call-back for moment when fingerprint 
> is available.
> The registration function returns immediately, so it is clear that the 
> callback will be called from another thread.
> 
> Is such situation supported by UFFI ?
> 
> Thanks for any tip,
> 
> Jan
> 
> Callbacks are supported. Here is an example...
> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-with-visitors-callbacks/
>  
> 
> 
> @Todd, How did find working through this part?  
> cheers -ben



Re: [Pharo-users] UFFI and Fortran

2017-11-08 Thread Todd Blanchard
I keep running into issues on 64 bit FFI.

Compiling 32 bit libraries is atypical and requires a lot of fiddling of 
unfamiliar build systems for various libraries so I'm just going to work in 64 
bit land on Mac.

> On Nov 6, 2017, at 7:25 PM, horrido  wrote:
> 
> That would be phenomenal! Let me know if and when it's done and I shall
> scream it out to all of social media!
> 
> 
> 
> tblanchard wrote
>> Yes - the reason I've been trying to learn FFI is specifically to get
>> TensorFlow integration.
>> 
>> I want a better ML workbench.
>> 
>>> On Nov 2, 2017, at 9:08 PM, Ben Coman <
> 
>> btc@
> 
>> > wrote:
>>> 
>>> 
>>> 
>>> On Fri, Nov 3, 2017 at 11:10 AM, horrido <
> 
>> horrido.hobbies@
> 
>>  
>> horrido.hobbies@
> 
>> >> wrote:
>>> Sounds like it's possible to call into TensorFlow (Python) from Pharo.
>>> That
>>> would give Pharo a tremendous boost for machine learning applications.
>>> 
>>> Am I right?
>>> 
>>> Tensorflow has a C API for FFI from other languages.
>>> * https://www.tensorflow.org/install/install_c
>>> ;
>>> * https://www.tensorflow.org/extend/language_bindings
>>> ;
>>> 
>>> cheers -ben
> 
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 




[Pharo-users] Objective C Bridge

2017-11-08 Thread Todd Blanchard


> On Oct 28, 2017, at 2:05 AM, Stephane Ducasse  wrote:
> 
> Hi andrew
> 
> you should contact esteban because he is writing an objective-C bridge. 
> 
> Stef

Another one?  I think we've written half a dozen now, no?  There is some code 
in the VM libs that allows calling out.  I worked on one with Avi for a bit 
about ten years ago.  The callbacks/delegate bit was always problematic.  It is 
one thing to call Objective C (really easy) but another thing to integrate with 
Cocoa and accept callbacks while keeping the VM live.

I would really love one that let me write Cocoa from Pharo (especially iPhone 
apps).  

I do wonder if this new capability with Objective C blocks wouldn't maybe make 
things easier. 
http://www.friday.com/bbum/2011/03/17/ios-4-3-imp_implementationwithblock/


Re: [Pharo-users] UFFI with asynchronous callbacks

2017-11-08 Thread Ben Coman
AFAIK, TalkFFI hasn't been updated to UFFI for Pharo 5.
http://forum.world.st/Porting-TalkFFI-LibClang-to-Pharo-5-UFFI-td4915060.html

cheers -ben

On Wed, Nov 8, 2017 at 4:07 PM, Todd Blanchard  wrote:

> Just catching up
>
> I'm trying to work with 64 bit Pharo 6.(1? 2?).
>
> I've run into some issues that I have not been able to resolve.  I've
> loaded up TalkFFI with the LibClang library and testLocation fails.
> Anything that tries to deal with getting a code location fails and I cannot
> figure out what the issue is yet.
>
> Also, callbacks do not work at all.
>
> One might say that this is only tested on 32 bit Pharo and that's fine,
> but I have a 64 bit computer loaded with 64 bit standard libraries and
> recompiling everything to get 32 bit versions is just not practical.  Its
> past time to do the 64 bit thing.
>
> FWIW, my test library at this point is SQLite Amalgam header to see if I
> can automatically build a SQLite interface (should be easy as it is one
> file) but it is kind of frustrating that these libclang features are not
> working on 64 bit libs.
>
> I have been running in lldb to try to catch the crashes, and I have
> written a number of toy programs to make certain things are the sizes I
> expect.
>
> Still stuck at this juncture.
>
> Had to take a lil break and learn to program a Particle board for a work
> project but will resume next week.
>
>
> On Oct 23, 2017, at 11:13 AM, Ben Coman  wrote:
>
>
>
> On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada  wrote:
>
>> Hi,
>>
>> I would like to connect fingerprint reader to pharo - so far I am able to
>> use C library to connect to it using UFFI,
>> however the problem is that I can wait for fingerprint indefinitely (
>> blocking call to library) or register call-back for moment when fingerprint
>> is available.
>> The registration function returns immediately, so it is clear that the
>> callback will be called from another thread.
>>
>> Is such situation supported by UFFI ?
>>
>> Thanks for any tip,
>>
>> Jan
>>
>
> Callbacks are supported. Here is an example...
> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-
> part-4-ast-walking-with-visitors-callbacks/
>
> @Todd, How did find working through this part?
> cheers -ben
>
>
>


Re: [Pharo-users] UFFI with asynchronous callbacks

2017-11-08 Thread Todd Blanchard
I know, but its closer to "done" than starting from scratch.



> On Nov 8, 2017, at 1:13 AM, Ben Coman  wrote:
> 
> AFAIK, TalkFFI hasn't been updated to UFFI for Pharo 5.
> http://forum.world.st/Porting-TalkFFI-LibClang-to-Pharo-5-UFFI-td4915060.html 
> 
> 
> cheers -ben
> 
> On Wed, Nov 8, 2017 at 4:07 PM, Todd Blanchard  > wrote:
> Just catching up
> 
> I'm trying to work with 64 bit Pharo 6.(1? 2?).
> 
> I've run into some issues that I have not been able to resolve.  I've loaded 
> up TalkFFI with the LibClang library and testLocation fails.  Anything that 
> tries to deal with getting a code location fails and I cannot figure out what 
> the issue is yet.
> 
> Also, callbacks do not work at all.  
> 
> One might say that this is only tested on 32 bit Pharo and that's fine, but I 
> have a 64 bit computer loaded with 64 bit standard libraries and recompiling 
> everything to get 32 bit versions is just not practical.  Its past time to do 
> the 64 bit thing.
> 
> FWIW, my test library at this point is SQLite Amalgam header to see if I can 
> automatically build a SQLite interface (should be easy as it is one file) but 
> it is kind of frustrating that these libclang features are not working on 64 
> bit libs.  
> 
> I have been running in lldb to try to catch the crashes, and I have written a 
> number of toy programs to make certain things are the sizes I expect.
> 
> Still stuck at this juncture.
> 
> Had to take a lil break and learn to program a Particle board for a work 
> project but will resume next week.
> 
> 
>> On Oct 23, 2017, at 11:13 AM, Ben Coman > > wrote:
>> 
>> 
>> 
>> On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada > > wrote:
>> Hi,
>> 
>> I would like to connect fingerprint reader to pharo - so far I am able to 
>> use C library to connect to it using UFFI,
>> however the problem is that I can wait for fingerprint indefinitely ( 
>> blocking call to library) or register call-back for moment when fingerprint 
>> is available.
>> The registration function returns immediately, so it is clear that the 
>> callback will be called from another thread.
>> 
>> Is such situation supported by UFFI ?
>> 
>> Thanks for any tip,
>> 
>> Jan
>> 
>> Callbacks are supported. Here is an example...
>> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-with-visitors-callbacks/
>>  
>> 
>> 
>> @Todd, How did find working through this part?  
>> cheers -ben
> 
> 



Re: [Pharo-users] UFFI with asynchronous callbacks

2017-11-08 Thread Denis Kudriashov
Hi.

Esteban has version ported to UFFI https://github.com/estebanlm/TalkFFI.
But I don't know is it working or not.

2017-11-08 10:15 GMT+01:00 Todd Blanchard :

> I know, but its closer to "done" than starting from scratch.
>
>
>
> On Nov 8, 2017, at 1:13 AM, Ben Coman  wrote:
>
> AFAIK, TalkFFI hasn't been updated to UFFI for Pharo 5.
> http://forum.world.st/Porting-TalkFFI-LibClang-to-Pharo-5-
> UFFI-td4915060.html
>
> cheers -ben
>
> On Wed, Nov 8, 2017 at 4:07 PM, Todd Blanchard  wrote:
>
>> Just catching up
>>
>> I'm trying to work with 64 bit Pharo 6.(1? 2?).
>>
>> I've run into some issues that I have not been able to resolve.  I've
>> loaded up TalkFFI with the LibClang library and testLocation fails.
>> Anything that tries to deal with getting a code location fails and I cannot
>> figure out what the issue is yet.
>>
>> Also, callbacks do not work at all.
>>
>> One might say that this is only tested on 32 bit Pharo and that's fine,
>> but I have a 64 bit computer loaded with 64 bit standard libraries and
>> recompiling everything to get 32 bit versions is just not practical.  Its
>> past time to do the 64 bit thing.
>>
>> FWIW, my test library at this point is SQLite Amalgam header to see if I
>> can automatically build a SQLite interface (should be easy as it is one
>> file) but it is kind of frustrating that these libclang features are not
>> working on 64 bit libs.
>>
>> I have been running in lldb to try to catch the crashes, and I have
>> written a number of toy programs to make certain things are the sizes I
>> expect.
>>
>> Still stuck at this juncture.
>>
>> Had to take a lil break and learn to program a Particle board for a work
>> project but will resume next week.
>>
>>
>> On Oct 23, 2017, at 11:13 AM, Ben Coman  wrote:
>>
>>
>>
>> On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada  wrote:
>>
>>> Hi,
>>>
>>> I would like to connect fingerprint reader to pharo - so far I am able
>>> to use C library to connect to it using UFFI,
>>> however the problem is that I can wait for fingerprint indefinitely (
>>> blocking call to library) or register call-back for moment when fingerprint
>>> is available.
>>> The registration function returns immediately, so it is clear that the
>>> callback will be called from another thread.
>>>
>>> Is such situation supported by UFFI ?
>>>
>>> Thanks for any tip,
>>>
>>> Jan
>>>
>>
>> Callbacks are supported. Here is an example...
>> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-
>> 4-ast-walking-with-visitors-callbacks/
>>
>> @Todd, How did find working through this part?
>> cheers -ben
>>
>>
>>
>
>


Re: [Pharo-users] UFFI with asynchronous callbacks

2017-11-08 Thread Todd Blanchard
Pretty sure that's the one I loaded.

Still having issues with libclang on 64 bit with code locations.

> On Nov 8, 2017, at 1:26 AM, Denis Kudriashov  wrote:
> 
> Hi.
> 
> Esteban has version ported to UFFI https://github.com/estebanlm/TalkFFI 
> . But I don't know is it working or 
> not. 
> 
> 2017-11-08 10:15 GMT+01:00 Todd Blanchard  >:
> I know, but its closer to "done" than starting from scratch.
> 
> 
> 
>> On Nov 8, 2017, at 1:13 AM, Ben Coman > > wrote:
>> 
>> AFAIK, TalkFFI hasn't been updated to UFFI for Pharo 5.
>> http://forum.world.st/Porting-TalkFFI-LibClang-to-Pharo-5-UFFI-td4915060.html
>>  
>> 
>> 
>> cheers -ben
>> 
>> On Wed, Nov 8, 2017 at 4:07 PM, Todd Blanchard > > wrote:
>> Just catching up
>> 
>> I'm trying to work with 64 bit Pharo 6.(1? 2?).
>> 
>> I've run into some issues that I have not been able to resolve.  I've loaded 
>> up TalkFFI with the LibClang library and testLocation fails.  Anything that 
>> tries to deal with getting a code location fails and I cannot figure out 
>> what the issue is yet.
>> 
>> Also, callbacks do not work at all.  
>> 
>> One might say that this is only tested on 32 bit Pharo and that's fine, but 
>> I have a 64 bit computer loaded with 64 bit standard libraries and 
>> recompiling everything to get 32 bit versions is just not practical.  Its 
>> past time to do the 64 bit thing.
>> 
>> FWIW, my test library at this point is SQLite Amalgam header to see if I can 
>> automatically build a SQLite interface (should be easy as it is one file) 
>> but it is kind of frustrating that these libclang features are not working 
>> on 64 bit libs.  
>> 
>> I have been running in lldb to try to catch the crashes, and I have written 
>> a number of toy programs to make certain things are the sizes I expect.
>> 
>> Still stuck at this juncture.
>> 
>> Had to take a lil break and learn to program a Particle board for a work 
>> project but will resume next week.
>> 
>> 
>>> On Oct 23, 2017, at 11:13 AM, Ben Coman >> > wrote:
>>> 
>>> 
>>> 
>>> On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada >> > wrote:
>>> Hi,
>>> 
>>> I would like to connect fingerprint reader to pharo - so far I am able to 
>>> use C library to connect to it using UFFI,
>>> however the problem is that I can wait for fingerprint indefinitely ( 
>>> blocking call to library) or register call-back for moment when fingerprint 
>>> is available.
>>> The registration function returns immediately, so it is clear that the 
>>> callback will be called from another thread.
>>> 
>>> Is such situation supported by UFFI ?
>>> 
>>> Thanks for any tip,
>>> 
>>> Jan
>>> 
>>> Callbacks are supported. Here is an example...
>>> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-with-visitors-callbacks/
>>>  
>>> 
>>> 
>>> @Todd, How did find working through this part?  
>>> cheers -ben
>> 
>> 
> 
> 



Re: [Pharo-users] UFFI with asynchronous callbacks

2017-11-08 Thread Esteban Lorenzano


> On 8 Nov 2017, at 06:55, Todd Blanchard  wrote:
> 
> Pretty sure that's the one I loaded.
> 
> Still having issues with libclang on 64 bit with code locations.

that was made for 32bit. 
I never tried it witht 64bit libclang so I would not expect it works just like 
that ;)

Esteban

> 
>> On Nov 8, 2017, at 1:26 AM, Denis Kudriashov > > wrote:
>> 
>> Hi.
>> 
>> Esteban has version ported to UFFI https://github.com/estebanlm/TalkFFI 
>> . But I don't know is it working or 
>> not. 
>> 
>> 2017-11-08 10:15 GMT+01:00 Todd Blanchard > >:
>> I know, but its closer to "done" than starting from scratch.
>> 
>> 
>> 
>>> On Nov 8, 2017, at 1:13 AM, Ben Coman >> > wrote:
>>> 
>>> AFAIK, TalkFFI hasn't been updated to UFFI for Pharo 5.
>>> http://forum.world.st/Porting-TalkFFI-LibClang-to-Pharo-5-UFFI-td4915060.html
>>>  
>>> 
>>> 
>>> cheers -ben
>>> 
>>> On Wed, Nov 8, 2017 at 4:07 PM, Todd Blanchard >> > wrote:
>>> Just catching up
>>> 
>>> I'm trying to work with 64 bit Pharo 6.(1? 2?).
>>> 
>>> I've run into some issues that I have not been able to resolve.  I've 
>>> loaded up TalkFFI with the LibClang library and testLocation fails.  
>>> Anything that tries to deal with getting a code location fails and I cannot 
>>> figure out what the issue is yet.
>>> 
>>> Also, callbacks do not work at all.  
>>> 
>>> One might say that this is only tested on 32 bit Pharo and that's fine, but 
>>> I have a 64 bit computer loaded with 64 bit standard libraries and 
>>> recompiling everything to get 32 bit versions is just not practical.  Its 
>>> past time to do the 64 bit thing.
>>> 
>>> FWIW, my test library at this point is SQLite Amalgam header to see if I 
>>> can automatically build a SQLite interface (should be easy as it is one 
>>> file) but it is kind of frustrating that these libclang features are not 
>>> working on 64 bit libs.  
>>> 
>>> I have been running in lldb to try to catch the crashes, and I have written 
>>> a number of toy programs to make certain things are the sizes I expect.
>>> 
>>> Still stuck at this juncture.
>>> 
>>> Had to take a lil break and learn to program a Particle board for a work 
>>> project but will resume next week.
>>> 
>>> 
 On Oct 23, 2017, at 11:13 AM, Ben Coman >>> > wrote:
 
 
 
 On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada >>> > wrote:
 Hi,
 
 I would like to connect fingerprint reader to pharo - so far I am able to 
 use C library to connect to it using UFFI,
 however the problem is that I can wait for fingerprint indefinitely ( 
 blocking call to library) or register call-back for moment when 
 fingerprint is available.
 The registration function returns immediately, so it is clear that the 
 callback will be called from another thread.
 
 Is such situation supported by UFFI ?
 
 Thanks for any tip,
 
 Jan
 
 Callbacks are supported. Here is an example...
 http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-with-visitors-callbacks/
  
 
 
 @Todd, How did find working through this part?  
 cheers -ben
>>> 
>>> 
>> 
>> 
> 



Re: [Pharo-users] [Pharo7.0a] Next batch of enhancements

2017-11-08 Thread Pavel Krivanek
2017-11-05 18:39 GMT+01:00 PBKResearch :

> I don’t see why there is a flame potential here; I certainly won’t start a
> flame war. My previous post was a bit heated, as a protest against the
> abuse of language; removing a facility may make Pharo easier to maintain,
> but it is not an enhancement for the user. I wasn’t aware that the theme is
> broken; it seems to work well whenever I use it.
>
>
>
> It may be that I am the only one weird enough to continue with this theme
> (which was the standard Pharo theme when I first met it). If so, I shall
> have to accept the majority view. I shall keep a note of the .st package
> you supplied, and try filing it in when I have to move on to Pharo 7. I
> don’t think keeping it as an optional extra will really work. It will be an
> orphan, because no-one other than the existing Pharo maintainers will have
> the knowledge to maintain it. It will presumably only need maintenance if
> there is some change in the superclass UITheme, and only those responsible
> for the change will know where the consequential effects will be seen.
>
>
>
> There is one possibility which occurs to me. You have presumably
> refactored the subclasses of UITheme, so that it no longer matters to the
> other themes whether watery is present or absent. So you could file it in
> again, marking it as deprecated and not to be maintained, and strange
> people like me could use it at our own risk. When some other change occurs
> which makes this theme irretrievably broken, perhaps in Pharo 8, 9 or 10,
> it could then be deleted.
>
>
>
> Definitely no flame – just a serious suggestion of a compromise.
>
>
>
> Peter Kenny
>

Hi Peter,

there are some other themes that are managed externally and if there will
be some issues with updating it to the latest Pharo versions, I'm sure that
people will help if they will be kindly asked. The Watery theme is working
in general but broken in many small details including the Spotter
integration. One thing that newcomers try to do as first is to play with
changing of themes and to provide them an inconsistent theme that emulates
look of an OS that is not used anymore does not throw a favorable light on
Pharo.

Cheers,
-- Pavel


>
> *From:* Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] *On
> Behalf Of *Pavel Krivanek
> *Sent:* 05 November 2017 12:48
> *To:* Any question about pharo is welcome 
> *Subject:* Re: [Pharo-users] [Pharo7.0a] Next batch of enhancements
>
>
>
> Removing of the Watery theme is an enhancement in sense of "cleanup". The
> code was not maintained and partly broken. To have this theme in the image
> was a problem for management of the two default Pharo themes because the
> Watery theme was superclass of them and added a significant level of
> complexity and mess.
>
>
>
> But let's be positive. I can imagine that this thread has a huge flame
> potential so I spent a few minutes to prepare Watery Theme as a standalone
> package (see the attached *.st file). And no, it was not a simple file-out
> operation. So I hope that people that want to use the Watery Theme will
> rather discuss in what repository to place it and who will maintain it. In
> Pharo we want to focus on two basic themes - one white and one dark. We
> simply see no reason why this theme should not be an optional external
> package.
>
>
>
> Cheers,
>
> -- Pavel
>
>
>
>
>
> 2017-11-05 12:00 GMT+01:00 PBKResearch :
>
> I waded through the list of 'enhancements', and was astonished to find
> this. Is there to be an alternative way of producing the same appearance as
> the 'Watery' theme? If not, how can the removal of a facility be called an
> 'enhancement'? I always switch to this theme when I load a new image,
> because I find the plain buttons in the standard theme ugly.
>
> I managed to find the fogbugz entry - not easy, because it has been
> closed, so clicking on the link gives 404 - and it just says 'UIThemeWatery
> should be removed according to the current Pharo 7 plans.' I can't recall
> seeing these plans put up for discussion; if I had, I would certainly have
> protested then. Does having this theme as an option cause any problems
> elsewhere, so as to justify removing a facility. If not, can I put in a
> plea to have this so-called enhancement reverted? It has been installed
> only a week ago, so it can't be a major problem.
>
> Peter Kenny
>
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf
> Of Stephane Ducasse
> Sent: 05 November 2017 09:08
> To: Pharo Development List ; Any question
> about pharo is welcome 
> Subject: [Pharo-users] [Pharo7.0a] Next batch of enhancements
>
> Report period: 23 October 2017 to 5 November 2017
>
> *  20587-remove-UIThemeWatery
>  >> https://pharo.fogbugz.com/f/cases/20587-remove-UIThemeWatery
>
>   Issue URL: https://pharo.fogbugz.com/f/cases/20587
>   PR URL: https://github.com/pharo-project/pharo/pull/395
>   Diff URL: https://github.com/pharo-project/phar

Re: [Pharo-users] Writing "powerpoint" like presentations in Pharo?

2017-11-08 Thread Offray Vladimir Luna Cárdenas


On 07/11/17 19:39, Sean P. DeNigris wrote:
> Offray Vladimir Luna Cárdenas-2 wrote
>> The idea of slides seems
>> pretty anachronistic/boring for making presentations.
> Amen, brother! Alan Kay would be proud :)
>

Maybe. I refer the whole aesthetics of slides (even the ones with
animations or simulations). You go in slide at the time, bullet point by
bullet point, loosing context and perspective. My usual approach is mind
maps. In [1] you can see the exported SVG version of the one I use in a
Grafoscopio workshop. Source code is in [2].

[1]
http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.svg
[2]
http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.mm

Cheers,

Offray



Re: [Pharo-users] UFFI with asynchronous callbacks

2017-11-08 Thread Esteban Lorenzano


> On 8 Nov 2017, at 05:07, Todd Blanchard  wrote:
> 
> Just catching up
> 
> I'm trying to work with 64 bit Pharo 6.(1? 2?).
> 
> I've run into some issues that I have not been able to resolve.  I've loaded 
> up TalkFFI with the LibClang library and testLocation fails.  Anything that 
> tries to deal with getting a code location fails and I cannot figure out what 
> the issue is yet.
> 
> Also, callbacks do not work at all.  

that’s unlikely to be true. 
what you will not have, definitively, is async callbacks (that’s WIP and not 
for the immediate).

Esteban

> 
> One might say that this is only tested on 32 bit Pharo and that's fine, but I 
> have a 64 bit computer loaded with 64 bit standard libraries and recompiling 
> everything to get 32 bit versions is just not practical.  Its past time to do 
> the 64 bit thing.
> 
> FWIW, my test library at this point is SQLite Amalgam header to see if I can 
> automatically build a SQLite interface (should be easy as it is one file) but 
> it is kind of frustrating that these libclang features are not working on 64 
> bit libs.  
> 
> I have been running in lldb to try to catch the crashes, and I have written a 
> number of toy programs to make certain things are the sizes I expect.
> 
> Still stuck at this juncture.
> 
> Had to take a lil break and learn to program a Particle board for a work 
> project but will resume next week.
> 
> 
>> On Oct 23, 2017, at 11:13 AM, Ben Coman > > wrote:
>> 
>> 
>> 
>> On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada > > wrote:
>> Hi,
>> 
>> I would like to connect fingerprint reader to pharo - so far I am able to 
>> use C library to connect to it using UFFI,
>> however the problem is that I can wait for fingerprint indefinitely ( 
>> blocking call to library) or register call-back for moment when fingerprint 
>> is available.
>> The registration function returns immediately, so it is clear that the 
>> callback will be called from another thread.
>> 
>> Is such situation supported by UFFI ?
>> 
>> Thanks for any tip,
>> 
>> Jan
>> 
>> Callbacks are supported. Here is an example...
>> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-with-visitors-callbacks/
>>  
>> 
>> 
>> @Todd, How did find working through this part?  
>> cheers -ben
> 



[Pharo-users] Soup bug(fix)

2017-11-08 Thread Siemen Baader
Hi all,

who maintains Soup, the HTML parser? Stef?

It seems to auto-close  (and ) tags when nested inside another
element. I wrote this test that fails:

testNestedButton
"this works with nested  tags instead of  and when there
is no enclosing  at all. but here  is auto-closed."

"a does not work either"

| soup |
soup := Soup
fromString:
'
text
   
'.
self assert: soup div button span string equals: 'text'




Where should I look to prevent Soup from auto-closing the tag, and where &
how should I submit my fix?

cheers,
Siemen


Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

2017-11-08 Thread Steffen Märcker
I see. How about the following (sketched) solution to avoid looping over  
all characters? It might be very well the case that you already considered  
(and dismissed) that path.


A) Assumption
In order to allow any meaningful matching, the input to the scanner is  
normalized according to the unicode spec.


B) Abstraction
Treat each character and character group of an regex as a set of intervals  
in the unicode code points. Lets call them "character tests" and lift the  
common set operations union, intersection and difference to them.


C) Construct NFA
NFA has potentially overlapping character tests at the transitions of each  
state.


D) Construct DFA
Given a product state s in the DFA and two transitions t1, t2 from the  
original NFA, add three new transitions to the DFA:
- a transition labeled with the character test of t1 minus the character  
test of t2
- a transition labeled with the intersection of the character tests of t1  
and t2
- a transition labeled with the character test of t2 minus the character  
test of t1


E) Extension
Instead of sets of unicode intervals we could also use test-functions,  
e.g. blocks. Then, in step D), the set operations are translated to  
boolean operations:

- difference t1 - t2 becomes: t1 && not t2
- intersection of t1 and t2 becomes: t1 && t2
This would allow to use optimized test functions, e.g., bdds, instead of  
relying on charcter tests only.



Cheers,
Steffen




Am .11.2017, 23:16 Uhr, schrieb Thierry Goubier  
:



Le 07/11/2017 à 23:00, Steffen Märcker a écrit :
I am not familiar with the literature on scanners. May I ask you about  
some details on the "for all characters" algorithms you are referring  
to?


The two main ones available, from the typical Aho/Ullman textbook, are:

- NFA to DFA conversion (i.e. build a NFA with your regular expressions,  
then convert it to a DFA)


- Direct regular expression to DFA construction

Both of them have loop of the type:

for (each input symbol a) {
...

Building a (or connecting to) a BDD library would be fun, indeed. But  
within that time frame it seems not realistic. Anyway, after finishing  
my thesis, I'd like to come back to that idea.


It would certainly be interesting. Please contact us again when you'll  
have time :)


Regards,

Thierry


Ciao, Steffen
  Am 7. November 2017 16:33:03 MEZ schrieb Andrew Glynn  
:
 A possible way to accomplish it would be to use an object graph  
with

an incremental query engine, such as EMF/CDO with Viatra or
something similar.  You could then put different character sets in
connected objects and query only as far as you need to.
 Andrew Glynn
 Sent from Mail  for
Windows 10
 *From: *Thierry Goubier 
*Sent: *Tuesday, November 7, 2017 7:17 AM
*To: *Any question about pharo is welcome

*Subject: *Re: [Pharo-users] Binary Decision Diagram Package in
Smalltalk
 Hi Andrew, Steffen,
 2017-11-07 13:10 GMT+01:00 Prof. Andrew P. Black mailto:bl...@cs.pdx.edu>>:
   > On 28 Oct 2017, at 17:37 , Steffen Märcker mailto:merk...@web.de>> wrote:
 >
 > Does that mean the sets/bdd would be constructed mainly at
comile time? Anyway, Andrew, feel free to contact me, I might
help you with this.
 >
 Thanks for the offer, Steffen!  The problem is that I need to
use SmaCC for my current project, and really do not have a month
to take off and re-design the way that it builds its scanner.  
I’ve talked to Thierry Goubier about, and he doesn’t have time

either!  It would be a fun project, though, and it ought to be
fairly separate from other parts of SmaCC.  I’ve spent a fair
bit of time thinking about how to do it, but don’t think that I
will be able to actually focus on it.
 Yes, this is the essence of the issue. There are a few alternatives
about it, but none we have the time to pursue.
  An alternative approach, which Thierry has suggested, is to  
make

SmaCC work on the UTF-8 representation of the Unicode.  Then we
could represent character sets as prefix trees.  But the core
problem would still exist: you can’t run an algorithm that
repeatedly executes
  for all characters in the alphabet do:
 when there are 2^21 characters in the alphabet!
 The main issue is that `for all characters`... All the literature  
on

scanner building uses 'for all characters do'.
 Thierry
   Andrew







Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

2017-11-08 Thread Thierry Goubier
Hi Steffen,

in fact, I considered B) directly, but not up to the point of building onto
C) and D) (with an obvious A, but that one is a given in Pharo
implementation of strings).

Thanks for the explanation, then.

Regards,

Thierry

2017-11-08 14:21 GMT+01:00 Steffen Märcker :

> I see. How about the following (sketched) solution to avoid looping over
> all characters? It might be very well the case that you already considered
> (and dismissed) that path.
>
> A) Assumption
> In order to allow any meaningful matching, the input to the scanner is
> normalized according to the unicode spec.
>
> B) Abstraction
> Treat each character and character group of an regex as a set of intervals
> in the unicode code points. Lets call them "character tests" and lift the
> common set operations union, intersection and difference to them.
>
> C) Construct NFA
> NFA has potentially overlapping character tests at the transitions of each
> state.
>
> D) Construct DFA
> Given a product state s in the DFA and two transitions t1, t2 from the
> original NFA, add three new transitions to the DFA:
> - a transition labeled with the character test of t1 minus the character
> test of t2
> - a transition labeled with the intersection of the character tests of t1
> and t2
> - a transition labeled with the character test of t2 minus the character
> test of t1
>
> E) Extension
> Instead of sets of unicode intervals we could also use test-functions,
> e.g. blocks. Then, in step D), the set operations are translated to boolean
> operations:
> - difference t1 - t2 becomes: t1 && not t2
> - intersection of t1 and t2 becomes: t1 && t2
> This would allow to use optimized test functions, e.g., bdds, instead of
> relying on charcter tests only.
>
>
> Cheers,
> Steffen
>
>
>
>
>
> Am .11.2017, 23:16 Uhr, schrieb Thierry Goubier  >:
>
> Le 07/11/2017 à 23:00, Steffen Märcker a écrit :
>>
>>> I am not familiar with the literature on scanners. May I ask you about
>>> some details on the "for all characters" algorithms you are referring to?
>>>
>>
>> The two main ones available, from the typical Aho/Ullman textbook, are:
>>
>> - NFA to DFA conversion (i.e. build a NFA with your regular expressions,
>> then convert it to a DFA)
>>
>> - Direct regular expression to DFA construction
>>
>> Both of them have loop of the type:
>>
>> for (each input symbol a) {
>> ...
>>
>> Building a (or connecting to) a BDD library would be fun, indeed. But
>>> within that time frame it seems not realistic. Anyway, after finishing my
>>> thesis, I'd like to come back to that idea.
>>>
>>
>> It would certainly be interesting. Please contact us again when you'll
>> have time :)
>>
>> Regards,
>>
>> Thierry
>>
>> Ciao, Steffen
>>>   Am 7. November 2017 16:33:03 MEZ schrieb Andrew Glynn <
>>> aglyn...@gmail.com>:
>>>  A possible way to accomplish it would be to use an object graph with
>>> an incremental query engine, such as EMF/CDO with Viatra or
>>> something similar.  You could then put different character sets in
>>> connected objects and query only as far as you need to.
>>>  Andrew Glynn
>>>  Sent from Mail  for
>>> Windows 10
>>>  *From: *Thierry Goubier 
>>> *Sent: *Tuesday, November 7, 2017 7:17 AM
>>> *To: *Any question about pharo is welcome
>>> 
>>> *Subject: *Re: [Pharo-users] Binary Decision Diagram Package in
>>> Smalltalk
>>>  Hi Andrew, Steffen,
>>>  2017-11-07 13:10 GMT+01:00 Prof. Andrew P. Black >> >:
>>>> On 28 Oct 2017, at 17:37 , Steffen Märcker >> > wrote:
>>>  >
>>>  > Does that mean the sets/bdd would be constructed mainly at
>>> comile time? Anyway, Andrew, feel free to contact me, I might
>>> help you with this.
>>>  >
>>>  Thanks for the offer, Steffen!  The problem is that I need to
>>> use SmaCC for my current project, and really do not have a month
>>> to take off and re-design the way that it builds its scanner.
>>>  I’ve talked to Thierry Goubier about, and he doesn’t have time
>>> either!  It would be a fun project, though, and it ought to be
>>> fairly separate from other parts of SmaCC.  I’ve spent a fair
>>> bit of time thinking about how to do it, but don’t think that I
>>> will be able to actually focus on it.
>>>  Yes, this is the essence of the issue. There are a few alternatives
>>> about it, but none we have the time to pursue.
>>>   An alternative approach, which Thierry has suggested, is to
>>> make
>>> SmaCC work on the UTF-8 representation of the Unicode.  Then we
>>> could represent character sets as prefix trees.  But the core
>>> problem would still exist: you can’t run an algorithm that
>>> repeatedly executes
>>>  

[Pharo-users] PharoLauncher directories

2017-11-08 Thread stephan
I run into all kinds of issues with the directory structure used by the 
new PharoLauncher. pharo-local seems to be shared now for multiple 
images. That makes using configurations practically impossible as they 
are not expecting to have to deal with pre-downloaded older and newer 
monticello files. The missing sources files is less of a problem.


Stephan




Re: [Pharo-users] LGit_GIT_ERROR: Invalid version 0 on git_remote_callbacks on latest 64bit 6.1 image?

2017-11-08 Thread Paulo R. Dellani
You need to configure Iceberg with the path of the SSH key
files you are using to authenticate with gitlab as well as the
passphrase to unlock the private key, I only got it working
after that. Have your done that?

There is more information in the README/FAQ here:

https://github.com/pharo-vcs/iceberg

Cheers,

Paulo

On 11/08/2017 12:26 AM, Tim Mackinnon wrote:
> Thanks for confirming this Esteban - perhaps I am doing something
> wrong - I tried using the steps I was using successfully several
> months ago namely:
>
> curl get.pharo.org/64/  | bash
> ./pharo-ui Pharo.image
>
> Which got me the latest image - which sys info says is (not sure why
> it still says 6.0 tho?):
>
> Pharo 6.0
> Latest update: #60520
>
> I then open Iceberg, and click on Clone Repository
>
> In the dialog I enter:
>
> g...@gitlab.com :macta/PharoLambda.git
> And put src in the code subdirectory field, and then click on Create.
>
> I get the LGit_GIT_ERROR ???
>
> Hmm, out of curiosity, I just tried leaving the src field empty and it
> then seemed to put an entry into Iceberg but then a Fetch gave me the
> same error?
>
> Tim
>
>> On 7 Nov 2017, at 11:46, Esteban Lorenzano > > wrote:
>>
>> iceberg should work on 64bits, both on Pharo7 and Pharo6. 
>> I’ve been using it exclusively on 64bits since some months now and I
>> know I’m not the only one… can you send a way to reproduce your
>> problem so I can take a look?
>>
>> Esteban
>>
>>
>>> On 6 Nov 2017, at 12:11, Tim Mackinnon >> > wrote:
>>>
>>> Hi - does Iceberg work on a 64bit image yet? I’ve not tried in a
>>> while, and was surprised when I went to get a new image via the
>>> command line that I am getting the error: LGit_GIT_ERROR: Invalid
>>> version 0 on git_remote_callbacks
>>>
>>> I can see a post by Alistair in Jun asking about this, and it seems
>>> 64bit hadn’t been updated to work back then - but is this still true
>>> in Nov?
>>>
>>> We seem very much in turmoil at the moment - and its unclear what
>>> should work and not work. Is there a stable platform? If 64 bit is
>>> only working for 7.x - should we remove it from 6.x so that people
>>> don’t inadvertently try to use it?
>>>
>>> Tim
>>
>



Re: [Pharo-users] QCMagritte on Github

2017-11-08 Thread Tobias Pape

> On 08.11.2017, at 08:15, stephan  wrote:
> 
> 
> Tobias told me he's also interested, so I assume he'll provide a modified 
> baseline for other platforms.

Modulo time, as always.
If the convex hull of the dependencies need too much changes for other 
platforms, I might have to drop that endeavor :/

-t


Re: [Pharo-users] QCMagritte on Github

2017-11-08 Thread stephan

On 08-11-17 20:53, Tobias Pape wrote:

Modulo time, as always. If the convex hull of the dependencies need
too much changes for other platforms, I might have to drop that
endeavor :/


And I trust you'll complain about our lack of responsible dependency
management in that case

Stephan




Re: [Pharo-users] Soup bug(fix)

2017-11-08 Thread Stephane Ducasse
Hi Siemen

let me know your loging and I can add you to commit. Paul is also
taking care of Soup.
Now I like XPath for scraping. Did you see the tutorial I wrote with Peter.


STef

On Wed, Nov 8, 2017 at 2:17 PM, Siemen Baader  wrote:
> Hi all,
>
> who maintains Soup, the HTML parser? Stef?
>
> It seems to auto-close  (and ) tags when nested inside another
> element. I wrote this test that fails:
>
> testNestedButton
> "this works with nested  tags instead of  and when there is
> no enclosing  at all. but here  is auto-closed."
>
> "a does not work either"
>
> | soup |
> soup := Soup
> fromString:
> '
> text
>
> '.
> self assert: soup div button span string equals: 'text'
>
> 
>
>
> Where should I look to prevent Soup from auto-closing the tag, and where &
> how should I submit my fix?
>
> cheers,
> Siemen



Re: [Pharo-users] Soup bug(fix)

2017-11-08 Thread PBKResearch
Siemen

Stef should have added that XPath depends on using Monty's XMLParser suite. I 
tried your snippet on XMLDOMParser, and it parses correctly. I always use 
XMLHTMLParser for parsing HTML, because I can always see the exact relationship 
between the parsed structure and the original HTML. With Soup I often found the 
match difficult or even impossible.

HTH

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Stephane Ducasse
Sent: 08 November 2017 21:19
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Soup bug(fix)

Hi Siemen

let me know your loging and I can add you to commit. Paul is also taking care 
of Soup.
Now I like XPath for scraping. Did you see the tutorial I wrote with Peter.


STef

On Wed, Nov 8, 2017 at 2:17 PM, Siemen Baader  wrote:
> Hi all,
>
> who maintains Soup, the HTML parser? Stef?
>
> It seems to auto-close  (and ) tags when nested inside 
> another element. I wrote this test that fails:
>
> testNestedButton
> "this works with nested  tags instead of  and when 
> there is no enclosing  at all. but here  is auto-closed."
>
> "a does not work either"
>
> | soup |
> soup := Soup
> fromString:
> '
> text
>
> '.
> self assert: soup div button span string equals: 'text'
>
> 
>
>
> Where should I look to prevent Soup from auto-closing the tag, and 
> where & how should I submit my fix?
>
> cheers,
> Siemen




Re: [Pharo-users] Soup bug(fix)

2017-11-08 Thread Kjell Godo
i like to collect some newspaper comics from an online newspaper
 but it takes really long to do it by hand by hand
i tried Soup but i didn’t get anywhere
 the pictures were hidden behind a script or something
is there anything to do about that? i don’t want to collect them all
i have the XPath .pdf but i haven’t read it yet

these browsers seem to gobble up memory
 and while open they just keep getting bigger till the OS session crash
 might there be a browser that is more minimal?

Vivaldi seems better at not bloating up RAM


Re: [Pharo-users] Soup bug(fix)

2017-11-08 Thread PBKResearch
Kjell

 

Almost certainly the HTML files will not contain the code for the actual 
pictures; they will just contain an ‘href’ node with the address to load the 
picture file from. If the web pages are built to a regular pattern, you should 
be able to parse them and locate the href nodes you want. 

 

I haven’t found any problem with the parse from XMLHTMLParser taking up too 
much memory. My machine has 4GB ram; if you have much less than that, you might 
have trouble. If you have found a systematic way to locate the picture file, 
you could minimise the size of the DOM the parser creates, by using a streaming 
parser. The streaming version of Monty’s parser is called StAXHTMLParser.

 

I have a bit of experience playing with these parsers. If you get stuck, ask 
again here with more details; I may be able to help.

 

Peter Kenny

 

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Kjell Godo
Sent: 08 November 2017 23:00
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Soup bug(fix)

 

i like to collect some newspaper comics from an online newspaper

 but it takes really long to do it by hand by hand

i tried Soup but i didn’t get anywhere

 the pictures were hidden behind a script or something

is there anything to do about that? i don’t want to collect them all

i have the XPath .pdf but i haven’t read it yet

 

these browsers seem to gobble up memory

 and while open they just keep getting bigger till the OS session crash

 might there be a browser that is more minimal?

 

Vivaldi seems better at not bloating up RAM



Re: [Pharo-users] Writing "powerpoint" like presentations in Pharo?

2017-11-08 Thread Andrew Glynn
I agree with you – on the rare occasions I do still do presentations I tend to 
use CompendiumNG, which is similar to a mind map but can contain any content, 
including multimedia content.  It was an Open University project but was used 
sufficiently elsewhere that when the Open University decided they were done 
with it the project was forked and continued by others.

It’s written in Java, currently I believe there’s no binary although it’s easy 
to build.  If you just wanted the installer jar to try it out though let me 
know.

Honestly though I’d probably still use Director if it weren’t for Adobe’s 
pricing.

Andrew Glynn

Sent from Mail for Windows 10

From: Offray Vladimir Luna Cárdenas
Sent: Wednesday, November 8, 2017 7:45 AM
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Writing "powerpoint" like presentations in Pharo?



On 07/11/17 19:39, Sean P. DeNigris wrote:
> Offray Vladimir Luna Cárdenas-2 wrote
>> The idea of slides seems
>> pretty anachronistic/boring for making presentations.
> Amen, brother! Alan Kay would be proud :)
>

Maybe. I refer the whole aesthetics of slides (even the ones with
animations or simulations). You go in slide at the time, bullet point by
bullet point, loosing context and perspective. My usual approach is mind
maps. In [1] you can see the exported SVG version of the one I use in a
Grafoscopio workshop. Source code is in [2].

[1]
http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.svg
[2]
http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.mm

Cheers,

Offray




Re: [Pharo-users] Writing "powerpoint" like presentations in Pharo?

2017-11-08 Thread Offray Vladimir Luna Cárdenas
I remember using CompendiumNG some time ago, but not for presentations.
Hopefully, we will have something better, with metamedium capabilities,
including embedding other media and make it programmable in Pharo,
without going to the "disastrous" slide metaphor.

Cheers,

Offray


On 08/11/17 20:31, Andrew Glynn wrote:
>
> I agree with you – on the rare occasions I do still do presentations I
> tend to use CompendiumNG, which is similar to a mind map but can
> contain any content, including multimedia content.  It was an Open
> University project but was used sufficiently elsewhere that when the
> Open University decided they were done with it the project was forked
> and continued by others.
>
>  
>
> It’s written in Java, currently I believe there’s no binary although
> it’s easy to build.  If you just wanted the installer jar to try it
> out though let me know.
>
>  
>
> Honestly though I’d probably still use Director if it weren’t for
> Adobe’s pricing.
>
>  
>
> Andrew Glynn
>
>  
>
> Sent from Mail  for
> Windows 10
>
>  
>
> *From: *Offray Vladimir Luna Cárdenas 
> *Sent: *Wednesday, November 8, 2017 7:45 AM
> *To: *pharo-users@lists.pharo.org 
> *Subject: *Re: [Pharo-users] Writing "powerpoint" like presentations
> in Pharo?
>
>  
>
>  
>
>  
>
> On 07/11/17 19:39, Sean P. DeNigris wrote:
>
> > Offray Vladimir Luna Cárdenas-2 wrote
>
> >> The idea of slides seems
>
> >> pretty anachronistic/boring for making presentations.
>
> > Amen, brother! Alan Kay would be proud :)
>
> > 
>
>  
>
> Maybe. I refer the whole aesthetics of slides (even the ones with
>
> animations or simulations). You go in slide at the time, bullet point by
>
> bullet point, loosing context and perspective. My usual approach is mind
>
> maps. In [1] you can see the exported SVG version of the one I use in a
>
> Grafoscopio workshop. Source code is in [2].
>
>  
>
> [1]
>
> http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.svg
>
> [2]
>
> http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.mm
>
>  
>
> Cheers,
>
>  
>
> Offray
>
>  
>
>  
>



Re: [Pharo-users] Writing "powerpoint" like presentations in Pharo?

2017-11-08 Thread Andrew Glynn
I was thinking of using it more for ideas of what works / what doesn’t.

Sent from Mail for Windows 10

From: Offray Vladimir Luna Cárdenas
Sent: Wednesday, November 8, 2017 9:50 PM
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Writing "powerpoint" like presentations in Pharo?

I remember using CompendiumNG some time ago, but not for presentations. 
Hopefully, we will have something better, with metamedium capabilities, 
including embedding other media and make it programmable in Pharo, without 
going to the "disastrous" slide metaphor.
Cheers,
Offray

On 08/11/17 20:31, Andrew Glynn wrote:
I agree with you – on the rare occasions I do still do presentations I tend to 
use CompendiumNG, which is similar to a mind map but can contain any content, 
including multimedia content.  It was an Open University project but was used 
sufficiently elsewhere that when the Open University decided they were done 
with it the project was forked and continued by others.
 
It’s written in Java, currently I believe there’s no binary although it’s easy 
to build.  If you just wanted the installer jar to try it out though let me 
know.
 
Honestly though I’d probably still use Director if it weren’t for Adobe’s 
pricing.
 
Andrew Glynn
 
Sent from Mail for Windows 10
 
From: Offray Vladimir Luna Cárdenas
Sent: Wednesday, November 8, 2017 7:45 AM
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Writing "powerpoint" like presentations in Pharo?
 
 
 
On 07/11/17 19:39, Sean P. DeNigris wrote:
> Offray Vladimir Luna Cárdenas-2 wrote
>> The idea of slides seems
>> pretty anachronistic/boring for making presentations.
> Amen, brother! Alan Kay would be proud :)
> 
 
Maybe. I refer the whole aesthetics of slides (even the ones with
animations or simulations). You go in slide at the time, bullet point by
bullet point, loosing context and perspective. My usual approach is mind
maps. In [1] you can see the exported SVG version of the one I use in a
Grafoscopio workshop. Source code is in [2].
 
[1]
http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.svg
[2]
http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.mm
 
Cheers,
 
Offray
 
 




Re: [Pharo-users] Writing "powerpoint" like presentations in Pharo?

2017-11-08 Thread Norbert Hartl
Everytime I read such discussions I wonder what happened to the Sophie code. 
There be might be some gems in it to achieve what you want

Norbert

> Am 09.11.2017 um 03:49 schrieb Offray Vladimir Luna Cárdenas 
> :
> 
> I remember using CompendiumNG some time ago, but not for presentations. 
> Hopefully, we will have something better, with metamedium capabilities, 
> including embedding other media and make it programmable in Pharo, without 
> going to the "disastrous" slide metaphor.
> 
> Cheers,
> 
> Offray
> 
>> On 08/11/17 20:31, Andrew Glynn wrote:
>> I agree with you – on the rare occasions I do still do presentations I tend 
>> to use CompendiumNG, which is similar to a mind map but can contain any 
>> content, including multimedia content.  It was an Open University project 
>> but was used sufficiently elsewhere that when the Open University decided 
>> they were done with it the project was forked and continued by others.
>>  
>> It’s written in Java, currently I believe there’s no binary although it’s 
>> easy to build.  If you just wanted the installer jar to try it out though 
>> let me know.
>>  
>> Honestly though I’d probably still use Director if it weren’t for Adobe’s 
>> pricing.
>>  
>> Andrew Glynn
>>  
>> Sent from Mail for Windows 10
>>  
>> From: Offray Vladimir Luna Cárdenas
>> Sent: Wednesday, November 8, 2017 7:45 AM
>> To: pharo-users@lists.pharo.org
>> Subject: Re: [Pharo-users] Writing "powerpoint" like presentations in Pharo?
>>  
>>  
>>  
>> On 07/11/17 19:39, Sean P. DeNigris wrote:
>> > Offray Vladimir Luna Cárdenas-2 wrote
>> >> The idea of slides seems
>> >> pretty anachronistic/boring for making presentations.
>> > Amen, brother! Alan Kay would be proud :)
>> > 
>>  
>> Maybe. I refer the whole aesthetics of slides (even the ones with
>> animations or simulations). You go in slide at the time, bullet point by
>> bullet point, loosing context and perspective. My usual approach is mind
>> maps. In [1] you can see the exported SVG version of the one I use in a
>> Grafoscopio workshop. Source code is in [2].
>>  
>> [1]
>> http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.svg
>> [2]
>> http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.mm
>>  
>> Cheers,
>>  
>> Offray
>>  
>>  
>