May 2016 - Pharo-users - lists.pharo.org

Call for feedbacks: Enterprise Pharo ePub version

by Thibault ARLOING

Hi, I created an ePub version of the book Enterprise Pharo for electronic readers. It would be great if you could test it and give me feedbacks on everything that shocks you. You can downlod the file here<http://files.pharo.org/books-ressources/entreprise-pharo/>. Thanks, Thibault

May 30, 2016

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

by Esteban A. Maringolo

Thanks all. There were several people that helped me along this endeavor and I thank again the Pharo Consortium for pushing this. 2016-05-30 5:04 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Good job, Esteban. > Now we need good Garage drivers for databases which not lock image. Does > anyone plan to work on Oracle and SQLServer backends? The Garage drivers got hurt by the changes in the FFI API (UFFI), but there are some people working on getting them back for Pharo 5. This is really important, and for those RDBMS you mention in particular, according to a survey [1] I did at the end of last year. We'll get there. Those willing to discuss issues or collaborate on these topics can always use this mailing list, but there is an active community of developers in the Pharo Project Slack team, we have one channel dedicated to database discussion [2]. Also, I copied the latest commit from the SmalltalkHub repo to GitHub in order to use its issue tracker [3] for bug reporting. Regards! [1] https://medium.com/@emaringolo/pharo-rdbms-support-survey-results-9c8f64087… [2] https://pharoproject.slack.com/messages/databases/ [3] https://github.com/DBXTalk/Glorp/issues

May 30, 2016

Re: [Pharo-users] Is lazy evaluation of infinite series possible?

by Hilaire

Did you take a look at Nicolai suggestion regarding the Generator class. There is a fibonacci example in its test case. fibo := GeneratorTest new fibonacciSequence then to access the sequence term: fibo next. Hilaire -- Dr. Geo http://drgeo.eu

May 30, 2016

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

by Peter Uhnak

I don't see anything actionable in this thread. What can we do to move this forward? Is it only up to Dale to change the behavior? Can we have some workaround? E.g. syncing in the background at regular intervals so when I want to commit I am not blocked by it? Because it doesn't always check the repos, and I don't see what is the actual trigger. Peter On Sun, May 29, 2016 at 02:28:48PM +0200, Thierry Goubier wrote: > Le 29/05/2016 14:04, Peter Uhnak a Ã©crit : > > On Sun, May 29, 2016 at 11:21:21AM +0200, Thierry Goubier wrote: > > > Le 29/05/2016 11:15, Peter UhnÃ¡k a Ã©crit : > > > > > All this is so that my .5 would not conflict with someone else .5 > > > > > > > > How is this a problem? Because it will be "Me.5" and "You.5", so there > > > > can't be any conflict. > > > > > > Me.5 and Me.5 are possible... > > > > > > Think of numbering your own stuff on two different branches. > > > > > > More, Metacello depends on Me.5 5 to be greater than You.5 5 for some of the > > > baselines / configurations to work properly :) > > > > Can't it use the ancestry to decide? > > I suggested that to Dale... Disregard version numbers, only consider as > newer if the other is in the ancestry chain. > > Would also be a lot more precise, because we would then use the package > version UID instead of the name.version number approximation which can leads > to failures or loading the wrong package in some cases. > > > Because my impression is from this that merges are naive, compared to > > git which actually checks the ancestry of both up the common endpoint > > and diffs based on that. > > This does not describe the Monticello merges. Monticello merges do walk the > ancestry chain to find a common ancestor and does a three way merge, as git > does. > > The problem is that the Monticello ancestry chain is often damaged for three > reasons: removing part of it to reduce memory usage (Done for the Pharo3 > release), removing all or part of it because your package ancestry chain is > too long (I remember seeing some packages doing that on purpose?), the > common ancestor doesn't exist anymore in the repositories visible to > Monticello (long-lived packages that have moved between repositories, > typically). > > When Monticello sees a version in the history, it expects the full package > to be available in the repositories; if this package is the common ancestor > of the merge and can't be retrieved, then the merge will fail. > > What GitFileTree/git does there is to ensure that if a version is in the > ancestry, it can be retrieved. Git merge also use that property. Any > GitFileTree-like layer would provide the same property (FossilFileTree, for > example). > > Note: in the git documentation, it is stated that git may create virtual > ancestors in some cases, to simplify/reduce the merge work. In such cases, > if set up, the gitfiletree merge driver will be called for all those merges > (i.e. a single merge in git may trigger multiple merges). > > Obvious, isn't it ;) > > Thierry > > > Peter > > > > > > > > Thierry > > > > > > > > > > > Peter > > > > > > > > On Sun, May 29, 2016 at 10:37 AM, Sven Van Caekenberghe <sven(a)stfx.eu > > > > <mailto:sven@stfx.eu>> wrote: > > > > > > > > > > > > > On 29 May 2016, at 10:28, Holger Freyther <holger(a)freyther.de <mailto:holger@freyther.de>> wrote: > > > > > > > > > > > > > > >> On 29 May 2016, at 09:58, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > >> > > > > >> > > > > >>> > > > > >>> For some reason the package manager is refreshing all packages. I don't know why it happens, and it's quite annoying (because it slows down commits), but it doesn't cause any actual problems, so don't worry about it too much. > > > > >> > > > > >> As I understand it, what happens is the following: before you commit to your MC repo, you have to find the next version number; a check is then done in all relevant repos; the cached content is not used, but an actual refresh is done. All this is so that my .5 would not conflict with someone else .5 - the chance that this happens is very small, and the check does not really prevent it. > > > > > > > > > > I assumed that but can it be limited to the Repositories that are associated with the package? I am afraid that next time I travel I can not commit to my local repository (and ofcourse the speed part). :) > > > > > > > > We should go one step further: add an option to totally disable this > > > > check to go outside the target repo, it makes little sense. But MC > > > > is a complex beast ... > > > > > > > > > holger > > > > > > > > > > > > > > > > > > > > > > > >

May 30, 2016

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