- Pharo-users - lists.pharo.org

Create PNG (from pdf?)

by Sabine Manaa

Hi, in my online application, I create pdf reports with artefact. Works great. Now, I want to show small previews of those reports with real data. I want them to be images (png). I am searching for ideas how to solve this. I have a list of advantages/disadvantages of various ways but no final idea/decision. I am very interested in ideas of the community. Perhaps someone had a similar problem? How did you solve this? Regards Sabine -- View this message in context: http://forum.world.st/Create-PNG-from-pdf-tp4898103.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 30, 2016

Re: [Pharo-users] Unified FFI: pointer of String as function parameter

by Julien Delplanque

On 30/05/16 11:44, Esteban Lorenzano wrote: >> On 30 May 2016, at 11:39, Julien Delplanque <julien(a)tamere.eu> wrote: >> >> I just did it, it works directly except for 2 little mistakes (for people who are interested): >> >> The class method to override in StringValueHolder is #typeDecl and not #typeDesc. >> >> To get the actual String from the StringValueHolder, no need to call #readString on the >> result of #value, it causes an error because #value already returns a String. > oh well, I was coding by heart ;) Indeed, I mean no offense, I just wanted to fix this for people who will need to do this in the future. :-p > >> Thanks a lot for this explanation Esteban :-). > youâre welcome :) > > Esteban > >> Regards, >> >> Julien >> >> On 30/05/16 11:14, Esteban Lorenzano wrote: >>> this is not the easiest part of FFI :) >>> >>> this is the simplest way: >>> >>> str := ExternalAddress new. âThis will point to NULLâ >>> self callToMyFunction: str. >>> pharoString := (str pointerAt: 1) readString. >>> >>> callToMyFunction: str >>> self ffiCall: #( void function ( char ** str ) ) >>> >>> >>> now, another way is to declare a value holder: >>> >>> 1) subclass FFIExternalValueHolder. >>> >>> FFIExternalValueHolder subclass: #StringValueHolder. >>> >>> 2) implement class side method typeDesc >>> >>> StringValueHolder class>>typeDesc >>> ^ String >>> >>> 3) implement your method replacing char** for your value holder: >>> >>> callToMyFunction: str >>> self ffiCall: #( void function ( StringValueHolder* str ) ) >>> >>> then you call like this: >>> >>> str := StringValueHolder new. >>> self callToMyFunction: str. >>> pharoString := str value readString. >>> >>> looks like too much steps for just economise the âpointeAt: 1â part, but is useful when you have lots of this calls :) >>> >>> cheers, >>> Esteban >>> >>> >>>> On 30 May 2016, at 10:56, Julien Delplanque <julien(a)tamere.eu> wrote: >>>> >>>> Hello everyone, >>>> >>>> I have a C function to call from Pharo that looks like this: >>>> >>>> int my_function(char ** parameter); >>>> >>>> This function fill the pointer on the String given as parameter. >>>> >>>> How can I use this from pharo Unified FFI? I mean, how to get a pharo String filled by this function? >>>> >>>> Thanks in advance, >>>> >>>> Julien >>>> >>>> >> >

May 30, 2016

Re: [Pharo-users] Unified FFI: pointer of String as function parameter

by Esteban Lorenzano

> On 30 May 2016, at 11:39, Julien Delplanque <julien(a)tamere.eu> wrote: > > I just did it, it works directly except for 2 little mistakes (for people who are interested): > > The class method to override in StringValueHolder is #typeDecl and not #typeDesc. > > To get the actual String from the StringValueHolder, no need to call #readString on the > result of #value, it causes an error because #value already returns a String. oh well, I was coding by heart ;) > > Thanks a lot for this explanation Esteban :-). youâre welcome :) Esteban > > Regards, > > Julien > > On 30/05/16 11:14, Esteban Lorenzano wrote: >> this is not the easiest part of FFI :) >> >> this is the simplest way: >> >> str := ExternalAddress new. âThis will point to NULLâ >> self callToMyFunction: str. >> pharoString := (str pointerAt: 1) readString. >> >> callToMyFunction: str >> self ffiCall: #( void function ( char ** str ) ) >> >> >> now, another way is to declare a value holder: >> >> 1) subclass FFIExternalValueHolder. >> >> FFIExternalValueHolder subclass: #StringValueHolder. >> >> 2) implement class side method typeDesc >> >> StringValueHolder class>>typeDesc >> ^ String >> >> 3) implement your method replacing char** for your value holder: >> >> callToMyFunction: str >> self ffiCall: #( void function ( StringValueHolder* str ) ) >> >> then you call like this: >> >> str := StringValueHolder new. >> self callToMyFunction: str. >> pharoString := str value readString. >> >> looks like too much steps for just economise the âpointeAt: 1â part, but is useful when you have lots of this calls :) >> >> cheers, >> Esteban >> >> >>> On 30 May 2016, at 10:56, Julien Delplanque <julien(a)tamere.eu> wrote: >>> >>> Hello everyone, >>> >>> I have a C function to call from Pharo that looks like this: >>> >>> int my_function(char ** parameter); >>> >>> This function fill the pointer on the String given as parameter. >>> >>> How can I use this from pharo Unified FFI? I mean, how to get a pharo String filled by this function? >>> >>> Thanks in advance, >>> >>> Julien >>> >>> >> > >

May 30, 2016

Re: [Pharo-users] Unified FFI: pointer of String as function parameter

by Julien Delplanque

I just did it, it works directly except for 2 little mistakes (for people who are interested): The class method to override in StringValueHolder is #typeDecl and not #typeDesc. To get the actual String from the StringValueHolder, no need to call #readString on the result of #value, it causes an error because #value already returns a String. Thanks a lot for this explanation Esteban :-). Regards, Julien On 30/05/16 11:14, Esteban Lorenzano wrote: > this is not the easiest part of FFI :) > > this is the simplest way: > > str := ExternalAddress new. âThis will point to NULLâ > self callToMyFunction: str. > pharoString := (str pointerAt: 1) readString. > > callToMyFunction: str > self ffiCall: #( void function ( char ** str ) ) > > > now, another way is to declare a value holder: > > 1) subclass FFIExternalValueHolder. > > FFIExternalValueHolder subclass: #StringValueHolder. > > 2) implement class side method typeDesc > > StringValueHolder class>>typeDesc > ^ String > > 3) implement your method replacing char** for your value holder: > > callToMyFunction: str > self ffiCall: #( void function ( StringValueHolder* str ) ) > > then you call like this: > > str := StringValueHolder new. > self callToMyFunction: str. > pharoString := str value readString. > > looks like too much steps for just economise the âpointeAt: 1â part, but is useful when you have lots of this calls :) > > cheers, > Esteban > > >> On 30 May 2016, at 10:56, Julien Delplanque <julien(a)tamere.eu> wrote: >> >> Hello everyone, >> >> I have a C function to call from Pharo that looks like this: >> >> int my_function(char ** parameter); >> >> This function fill the pointer on the String given as parameter. >> >> How can I use this from pharo Unified FFI? I mean, how to get a pharo String filled by this function? >> >> Thanks in advance, >> >> Julien >> >> >

May 30, 2016

Re: [Pharo-users] Unified FFI: pointer of String as function parameter

by Julien Delplanque

Thanks for the fast answer. :-) On 30/05/16 11:14, Esteban Lorenzano wrote: > this is not the easiest part of FFI :) > > this is the simplest way: > > str := ExternalAddress new. âThis will point to NULLâ > self callToMyFunction: str. > pharoString := (str pointerAt: 1) readString. > > callToMyFunction: str > self ffiCall: #( void function ( char ** str ) ) > > > now, another way is to declare a value holder: > > 1) subclass FFIExternalValueHolder. > > FFIExternalValueHolder subclass: #StringValueHolder. > > 2) implement class side method typeDesc > > StringValueHolder class>>typeDesc > ^ String > > 3) implement your method replacing char** for your value holder: > > callToMyFunction: str > self ffiCall: #( void function ( StringValueHolder* str ) ) > > then you call like this: > > str := StringValueHolder new. > self callToMyFunction: str. > pharoString := str value readString. > > looks like too much steps for just economise the âpointeAt: 1â part, but is useful when you have lots of this calls :) I think I will use the second solution. It is cleaner isn't it? Julien

May 30, 2016

Re: [Pharo-users] Unified FFI: pointer of String as function parameter

by Esteban Lorenzano

this is not the easiest part of FFI :) this is the simplest way: str := ExternalAddress new. âThis will point to NULLâ self callToMyFunction: str. pharoString := (str pointerAt: 1) readString. callToMyFunction: str self ffiCall: #( void function ( char ** str ) ) now, another way is to declare a value holder: 1) subclass FFIExternalValueHolder. FFIExternalValueHolder subclass: #StringValueHolder. 2) implement class side method typeDesc StringValueHolder class>>typeDesc ^ String 3) implement your method replacing char** for your value holder: callToMyFunction: str self ffiCall: #( void function ( StringValueHolder* str ) ) then you call like this: str := StringValueHolder new. self callToMyFunction: str. pharoString := str value readString. looks like too much steps for just economise the âpointeAt: 1â part, but is useful when you have lots of this calls :) cheers, Esteban > On 30 May 2016, at 10:56, Julien Delplanque <julien(a)tamere.eu> wrote: > > Hello everyone, > > I have a C function to call from Pharo that looks like this: > > int my_function(char ** parameter); > > This function fill the pointer on the String given as parameter. > > How can I use this from pharo Unified FFI? I mean, how to get a pharo String filled by this function? > > Thanks in advance, > > Julien > >

May 30, 2016

Unified FFI: pointer of String as function parameter

by Julien Delplanque

Hello everyone, I have a C function to call from Pharo that looks like this: int my_function(char ** parameter); This function fill the pointer on the String given as parameter. How can I use this from pharo Unified FFI? I mean, how to get a pharo String filled by this function? Thanks in advance, Julien

May 30, 2016

Mongo-BSON OID LargePositiveInteger increase

by Holger Freyther

Hi, I tried to reach the author for several weeks but he doesn't seem to respond so I am trying to reach a wider audience to either confirm my suspicion or to be corrected. In http://smalltalkhub.com/#!/~MongoTalkTeam/mongotalk/diff/Mongo-BSON-HenrikS… the following change is done: + "digitAdd: wraps around to 0 when result would overflow" + ^ counter := counter + ifNil:[self newCounter] + ifNotNil:[counter digitAdd: 1]! - ^ counter := (counter + 1) \\ 16rFFFFFF! The old code has overflow checking, the new code makes a statement I don't think is true. counter is LargePositiveInteger new: 3 to use three bytes. So given the above code and the experiment (yes I could just add a bigger number) | id | id := LargePositiveInteger. 1 to: (16777215 + 50) do: [:each | id := id digitAdd: 1]. id. Given the comment it should overflow and the value be 50? This is not what the result is. So shall the truncation be added again or at least the comment be updated? The code will go from LargePositiveInteger to SmallInteger when overflowing from three to four bytes but luckily >>#value ... replaceFrom: 1 to: 3 with: self class counterNext startingAt: 1 will even work when counterNext returns a SmallInteger. But given the old code and the comment in the new code this is does not seem to function as intended? kind regards holger PS: The other part is that >>#newCounter doesn't seem to be ever executed. On first load >>#initialize will call >>#reset and on >>#shutDown: calls reset. So the code to "randomize" the initial counter doesn't seem to work.

May 30, 2016

Re: [Pharo-users] [ANN] New Pharo Glorp version and Book chapter

by Sven Van Caekenberghe

Great work and well done, Esteban, much appreciated. Thank you ! > On 29 May 2016, at 20:27, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Hello all, > > During the first part of the year, and sponsored by the Pharo > Consortium, I started a new port of Glorp, the Object-Relational > mapper, based on the latest version available in VW 8.0.1. > > This latest port was done from scratch in Pharo and brings features > and bugfixes that were accumulated in the VW port during more than 5 > years (previous Pharo port) and weren't available until now; and it > uses the Garage database drivers (but not limited to them). > > During the last couple of months, and also by request of the > Consortium, I wrote a chapter for one of the Pharo books describing > Glorp as much as possible, with tutorials and key concepts. The > chapter ended up being the longest in text and pages of all written; > the domain is so broad and deep that I'm considering taking it to a > whole book, who knows... > > The book is available at > <https://ci.inria.fr/pharo-contribution/job/PharoBookWorkInProgress/lastSucc…>, > and I will welcome suggestions and corrections as pull requests to > <https://github.com/SquareBracketAssociates/PharoInProgress> > > The Glorp repository is the same as the previous one > (http://www.smalltalkhub.com/#!/~DBXTalk/Glorp) and the current > Metacello configs will load the previous version for Pharo 4 and the > new version for Pharo 5. For the foreseeable future I'll continue > maintaining Glorp, but the code is MIT and I'm open to contributions > (I'll set up a Github repo in the next days). > > Also I've been running production software based on Glorp for a few > years now, so my experience with it cover most of its features and > usage patterns, so if you have particular questions not covered by the > book chapter or any other material feel free to ask me, this mailing > list or to the Glorp mailing list at <glorp-group(a)googlegroups.com>. > > Best regards! > > Esteban A. Maringolo >

May 30, 2016

Re: [Pharo-users] [ANN] New Pharo Glorp version and Book chapter

by phil＠highoctane.be

Esteban, Thanks a lot for this, it really is a great (and much needed) resource! Phil On Sun, May 29, 2016 at 8:27 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hello all, > > During the first part of the year, and sponsored by the Pharo > Consortium, I started a new port of Glorp, the Object-Relational > mapper, based on the latest version available in VW 8.0.1. > > This latest port was done from scratch in Pharo and brings features > and bugfixes that were accumulated in the VW port during more than 5 > years (previous Pharo port) and weren't available until now; and it > uses the Garage database drivers (but not limited to them). > > During the last couple of months, and also by request of the > Consortium, I wrote a chapter for one of the Pharo books describing > Glorp as much as possible, with tutorials and key concepts. The > chapter ended up being the longest in text and pages of all written; > the domain is so broad and deep that I'm considering taking it to a > whole book, who knows... > > The book is available at > < > https://ci.inria.fr/pharo-contribution/job/PharoBookWorkInProgress/lastSucc… > >, > and I will welcome suggestions and corrections as pull requests to > <https://github.com/SquareBracketAssociates/PharoInProgress> > > The Glorp repository is the same as the previous one > (http://www.smalltalkhub.com/#!/~DBXTalk/Glorp) and the current > Metacello configs will load the previous version for Pharo 4 and the > new version for Pharo 5. For the foreseeable future I'll continue > maintaining Glorp, but the code is MIT and I'm open to contributions > (I'll set up a Github repo in the next days). > > Also I've been running production software based on Glorp for a few > years now, so my experience with it cover most of its features and > usage patterns, so if you have particular questions not covered by the > book chapter or any other material feel free to ask me, this mailing > list or to the Glorp mailing list at <glorp-group(a)googlegroups.com>. > > Best regards! > > Esteban A. Maringolo > > >

May 30, 2016