- Pharo-users - lists.pharo.org

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

by Evan Donahue

Hello, Other people are probably better qualified to weigh in on the best ways to manage packages in a Pharo image, but this is what I do: 1) Left click on the "desktop" to bring up the "world menu" and select "Monticello Browser." 2) Click the "+Repository" button and select "smalltalkhub.com" from the popup menu. 3) Type 'EvanDonahue' and 'Lazy' inside the provided quotes next to owner: and project:, respectively (user and password can be left ''). Then click OK. 4) Highlight "Lazy-Core-EvanDonahue.26.mcz" on the right panel (may be 26 or any other number) and click the "Browse" button to explore the classes and methods without actually installing in your image. 5) Click the "Load" button to install the classes in the image. You may also want to install Lazy-Tests just to have some code examples to look at. 6) To remove everything later, open Monticello again, search for "Lazy," right-click Lazy-Core in the left pane, and "unload" As for your use case, what you have written should work, but if you just want a ton of 1's, you can use LazyList repeat: 1 There are other class methods of increasing generality for generating infinite lists, but of course you can always use #collect: and friends to compose appropriately. LazyList is technically still "under development," but it should be feature complete for most uses. Let me know if there's any functionality it's missing, or if you're wondering whether and how it can do something. If you want to say any more about the operations you are trying to perform, I can be more specific about how to do them. Roughly, aside from the infinite methods, the API follows the standard Pharo collections. And also welcome to Pharo. It's a trip. Cheers, Evan -- View this message in context: http://forum.world.st/Is-lazy-evaluation-of-infinite-series-possible-tp4897… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 30, 2016

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

by Pablo R. Digonzelli

Excellent Esteban. Thanks a lot !!!! Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Dividato SA 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Esteban A. Maringolo" <emaringolo(a)gmail.com> Para: "Pharo users" <pharo-users(a)lists.pharo.org>, "GLORP Mailing List" <glorp-group(a)googlegroups.com> Enviados: Domingo, 29 de Mayo 2016 15:27:17 Asunto: [ANN] New Pharo Glorp version and Book chapter 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 -- You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to glorp-group+unsubscribe(a)googlegroups.com. To post to this group, send email to glorp-group(a)googlegroups.com. Visit this group at https://groups.google.com/group/glorp-group. For more options, visit https://groups.google.com/d/optout.

May 30, 2016

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

by Pablo R. Digonzelli

Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Dividato SA 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Esteban A. Maringolo" <emaringolo(a)gmail.com> Para: "Pharo users" <pharo-users(a)lists.pharo.org>, "GLORP Mailing List" <glorp-group(a)googlegroups.com> Enviados: Domingo, 29 de Mayo 2016 15:27:17 Asunto: [ANN] New Pharo Glorp version and Book chapter Excellent, thanks a lot!!!! 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 -- You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to glorp-group+unsubscribe(a)googlegroups.com. To post to this group, send email to glorp-group(a)googlegroups.com. Visit this group at https://groups.google.com/group/glorp-group. For more options, visit https://groups.google.com/d/optout.

May 30, 2016

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

by Erisa

I took a look at the numerical methods book, but it seems oriented to actually evaluating an infinite series up to a certain accuracy. With formal power series all we want are the coefficients. For example, consider the series S = 1 + x + x^2 + x^3 + ... The coefficients are an infinite list [1, 1, ...]. What I need is a class for S that would allow me to perform operations such as addition, multiplication, etc. Thus I would like to able to do S * S and get the infinite list of the coefficients [1, 2, 3, 4, ...] and view say the first 10 or perhaps the nth coefficient. Your LazyList looks promising. To create the series this seems like it would work. s := LazyList wholes collect: [ :n | 1 ] But defining the operations is the difficult part. I would like to look at your package, but I need some help. How can I download your package from smalltalk hub so that I can examine it, play with it, but eventually easily remove it if I want. As you can tell, I have just started learning Pharo. -- View this message in context: http://forum.world.st/Is-lazy-evaluation-of-infinite-series-possible-tp4897… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 29, 2016

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

by stepharo

Hello Erisa > I am just learning Pharo (taking the MOOC actually!) :) > and am wondering whether > it is possible to model formal power series. I have done this in Haskell > quite easily and efficiently, but struggled to do it in Python without real > success. It requires one to perform operations on an infinite stream (such > as multiplying two infinite power series). One then only evaluates the > terms as they are needed, i.e., lazily. Any thoughts? I'm eager to hear what other and you will say. Now since blocks are closures, and I remember that long time ago I implemented simply infinite stream with a closure in CLOS it should be a same in Pharo. Now it was probably 20 years ago so I forgot the exact implementation. I hope that you have fun with our neat language. Stef > > > > -- > View this message in context: http://forum.world.st/Is-lazy-evaluation-of-infinite-series-possible-tp4897… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

May 29, 2016

Re: [Pharo-users] (no subject)

by stepharo

Le 29/5/16 Ã 12:04, frankl1_miky a Ã©crit : > Thanks for all your answers, It's true that pharo community is active. > > I'll give you feedback about my progress. > > I'm having fun with Pharo Mooc at this period. I'm happy to see that all the energy I put in the mooc is useful :) > > Thanks for your help! > > > > -- > View this message in context: http://forum.world.st/no-subject-tp4894192p4897990.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

May 29, 2016

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

by stepharo

>>>> 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 would be cool because you imagine when we integrate a change :) > it makes little sense. But MC is a complex beast ... > >> holger > >

May 29, 2016

[ANN] New Pharo Glorp version and Book chapter

by Esteban A. Maringolo

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 29, 2016

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

by Evan Donahue

Hello, I know infinite series are mentioned in the numerical methods book, although I haven't worked with those classes specifically. http://files.pharo.org/books/numerical-methods/2016-04-NumericalMethods.pdf You could also use a LazyList, depending on what you were doing, from http://smalltalkhub.com/#!/~EvanDonahue/Lazy/ x := 3. Float e raisedTo: x. " = 20.085536923187664" eX := LazyList wholes collect: [ :n | (x raisedTo: n) / n factorial ]. (eX take: 20) sum asFloat. " = 20.085536921517672" 2 * (Float e raisedTo: x). " = 40.17107384637533" twoEX := eX with: eX collect: [ :a :b | a + b ]. (twoEX take: 20) sum asFloat. " = 40.171073843035344" Will either of those work? Evan -- View this message in context: http://forum.world.st/Is-lazy-evaluation-of-infinite-series-possible-tp4897… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 29, 2016

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

by Thierry Goubier

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 29, 2016