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

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

by Werner Kassens

Hi Erisa, one solution, using your notation, could eg be * aPowerSeries ^ PowerSeries on: [ :generator | |a b| a:=OrderedCollection new. b:=OrderedCollection new. [ a add: self next. b add: aPowerSeries next. generator yield: a asDhbVector * b asDhbVector reverse ] repeat ] the multiplication of DhbVectors is the same as your ".*". DhbVector is not in the standard pharo, it is part of the polymath project, i was just too lazy to program that part by hand, but changing that should be no problem. werner On 05/30/2016 09:47 PM, Erisa wrote: > The fibonacciSequence example was really helpful. I made a new class > PowerSeries, a subclass of Generator. Then I defined a binary operation + > as follows: > > + aPowerSeries > ^ PowerSeries on: [ :ps | > | a b | > [ a := self next. > b := aPowerSeries next. > ps yield: (a + b) ] > repeat ] > > This works perfectly. But now I am struggling with how to define > multiplication. When I do PS1 * PS2, the first yield should be a := PS1 > next. b := PS2 next. ps yield (a * b). Thereafter would come the > PowerSeries, call it PSNew, (PS2 .* a) + (PS1 * PS2'), where .* is scalar > multiplication (easy to implement) and PS2' is the original PS2 (i.e., > rewound 1). I see several problems here. It looks like I need a way to > clone (fork?) a PowerSeries since in this computation I need both the > current PS2 and the original PS2 and be able to operate with them > independently. Second, how do I define the generator so that it first > yields the scalar (a*b) and thereafter is represented by the PowerSeries > PSNew? Finally, will the recursion in the definition of * blow up rapidly? > > > > -- > 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. > >

June 6, 2016

Re: Pharo 5 accented chars bug/regression

by Milan Vavra

Hi I have a solution for the problem you mentioned. I know what needs to be done to be able to type those pesky e with caron, c with caron and uppercase C with caron characters on Pharo 3, 4 and 5 on Windows. But I want you to do something for me in return. I want you to go to stackoverflow.com, and ask a question about this problem there. Post the link to your question here. I will answer it. If my solution works for you, you tag it as a solution and I get stackoverflow.com karma. Deal? Milan -- View this message in context: http://forum.world.st/Pharo-5-accented-chars-bug-regression-tp4898863p48993… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 6, 2016

Re: [Pharo-users] Pharo Catalog broken?

by Esteban Lorenzano

Yes is broken, and I'm traveling so I will not be able to fix it until this afternoon :( Esteban > On 6 Jun 2016, at 13:50, Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com> wrote: > > Hello everybody, > > it looks like the pharo catalog has a problem with the database: if I query the web service, or browse the page http://catalog.pharo.org/, I get the following error. > > VOMongoError: Lazy reference not found CatalogRepository: OID(67173037322134959457277313026) > > Maybe some aggressive cleanup? > > > Tommaso > >

June 6, 2016

Pharo Catalog broken?

by Tommaso Dal Sasso

Hello everybody, it looks like the pharo catalog has a problem with the database: if I query the web service, or browse the page http://catalog.pharo.org/, I get the following error. VOMongoError: Lazy reference not found CatalogRepository: OID(67173037322134959457277313026) Maybe some aggressive cleanup? Tommaso

June 6, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Christophe Demarey

Hi Doru, I think most people understand the great value of moldable tools. Maybe not all will use moldability but is a big plus to have. So, keep pushing! I just think we miss time to make the GT Debugger dealt view as productive as the spec debugger. There are users that do not use shortcuts (at least for debugger) and in this case, the over use of the mouse to reach step buttons is killing the productivity. To me, this issue could be addressed easily but could take time to implement in a generic / moldable way. I agree with Gabriel that buttons act on the stack (in fact also, on the source code pane that represents the AST) but what we mainly look at is the source code. Maybe buttons could be moved to the source code pane? I also have another suggestion: I very often have a debugger window with a lot of variables not visible by default : only 4 visible, need to scroll. Couldnât we split the variable pane in 2 part to display more variables? To open the inspector, you could either use the second column or open a third one. WDYT? Cheers, Christophe > Le 4 juin 2016 Ã 08:45, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > Hi Sabine (and others that asked this question), > > Thanks for the feedback. Sorry for the delayed reply, but I am traveling these days and I have limited online time. Also, this email took some time to write (I started it about a week ago). > > I will answer the buttons issue. The reason they are in a different place than where they used to be is related to new constraints that come with the new debugger. While the default interface looks like a regular debugger, the main feature of the GTDebugger is that it can be customized to match a specific domain or library. > > Let me provide an example of a scenario of debugging PetitParser: > > PPArithmeticParser parse: '1+2*3^(34-2)â > > The default debugger looks like this: > > <debug-pp-default.png> > > But, because we have PetitParser code on the stack, we can switch to a custom debugger: > > <debug-pp-dedicated-source.png> > > This one also features the input stream next to the code. Also, note that the stack received 3 new button actions. But, this is not all. Next to the source, there are other tabs, and we can switch to one of those: > > <debug-pp-dedicated-visualization.png> > > This one shows the source as well, but in a graphical form. > > So, if we step back and talk about the buttons, you will see that if we would have put the buttons on the source tabs, you have had no way to advance in this state. We could have also duplicated behavior and put the buttons on the new presentation as well, but the space is much smaller and since we now have large buttons instead of only icons we needed to deal with that as well. We encountered similar situations in other debuggers (not all, though). > > But, from a more point of view, the actions act on the stack. So, if we take an object-oriented approach for designing the UI, it makes sense to place those actions next to the context they act on. All these reasons made us choose to put them next to the stack and not next to the source. > > We certainly understand that this is a departure from the classic debugger and perhaps this is not the best way of doing things, but that was the rationale we went through. I would be happy to hear other suggestions, but please understand that we need to take into account the full spectrum of constraints when choosing solutions. > > In any case, the idea of this debugger is that you can change it in the way you want and customize it specifically for your needs. We still need to document how to do that, but if someone wants to start creating a custom debugger we could use the experience to drive the documentation. > > Does this explain the situation? > > Cheers, > Doru > > >> On May 25, 2016, at 9:43 PM, Sabine Manaa <manaa.sabine(a)gmail.com <mailto:manaa.sabine@gmail.com>> wrote: >> >> Hi, >> >> today I moved to Pharo5. It is great to get feedback and solutions for >> problems so quickly. It is a pleasure to work with Pharo and to have the >> community. I am grateful for having this. >> >> I have one comment. I don't want to complain, I can use it but I was >> wondering about the new position and size of the debugger buttons. >> >> There is a longer distance now from code text pane to the buttons - I see >> this as disadvantage to earlier versions of Pharo from the user experience. >> The buttons are a lot of smaller - same disadvantage - both if you use the >> mouse. >> >> Ok, after seeing that, I thought "Sabine, you should use keyboard shortcuts >> here, too" (I use much of them but interesting - til now not in the >> debugger). >> >> Then I saw the shortcuts for >> Proceed cmd+r >> Restart cmd-shift-a >> Into cmd-e >> over cmd-shift-o >> through cmd-shift-t >> >> especially into, over and through have so different key combinations, two >> with shift, one without shift. When I debug, I often use for example >> into-into-over-over-over-throuhg-through--into-into etc...and with the >> combinations cmd-e and cmd-shit-e, it is more "finger-work". It would be >> better to have all those shortcuts with or all shortcuts without shift. And >> the letters not so far away at the keyboard (e-o-t) >> >> This is only my opinion and my first impression after one day with Pharo5. I >> am sure, after a few days, I forgot that this was uncomfortable because I >> have the shortcuts coming automatically into my fingers. >> >> Regards >> Sabine >> >> >> >> >> >> >> -- >> View this message in context: http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390.html <http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390.html> >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com <http://nabble.com/>. >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com > > "Every thing should have the right to be different." > > > >

June 6, 2016

Spur Cog vs VW

by Gerry Weaver

Hi, I saw a post with the title "Spur Cog vs VW". Has anyone done this yet? Is there some code available somewhere that I could run? I have been searching on Google, but I haven't found much. A pointer in the right direction would be much appreciated. I'm really curious ;-) Thanks, -G

June 6, 2016

Re: [Pharo-users] OSProcess command with german umlaut does not work

by Sabine Manaa

Hi Dave, I get the german Ã¤ with: (Character value: 228) asString Do you want me to go in it and suggest a solution or do you want to try to fix it and I test it? Thanks for helping! Regards Sabine 2016-06-05 23:08 GMT+02:00 David T. Lewis [via Smalltalk] < ml-node+s1294792n4899301h26(a)n4.nabble.com>: > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/OSProcess-command-with-german-umlaut-does-not-work-tp… > To start a new topic under Pharo Smalltalk Users, email > ml-node+s1294792n1310670h65(a)n4.nabble.com > To unsubscribe from Pharo Smalltalk Users, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/OSProcess-command-with-german-umlaut-does-not-work-tp… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 6, 2016

Re: [Pharo-users] [ANN] Glorp-SQLite3 for Pharo 5

by Esteban A. Maringolo

The Glorp port Pierce is refering to, as well as its UDBC-SQLite3 library are meant to be used in Pharo 5. The NB (for NativeBoost) are Pharo 4 things. Regards! Esteban A. Maringolo 2016-06-05 19:38 GMT-03:00 francescoagati <francescoagati1975(a)gmail.com>: > yes with 32 bits is ok. i try to use this tutorial for pharo 4. but some > references are changed. > > http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2015-January/0… > > NBSQLite3DatabaseAccessor isn't present. i have substitute with > DatabaseAccessor. > but i have this error unable to connect > > > > -- > View this message in context: http://forum.world.st/ANN-Glorp-SQLite3-for-Pharo-5-tp4899277p4899308.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

June 6, 2016

Re: [Pharo-users] [ANN] Glorp-SQLite3 for Pharo 5

by Esteban A. Maringolo

2016-06-05 18:29 GMT-03:00 francescoagati <francescoagati1975(a)gmail.com>: > tested on windows 7 with sqlite 32 bit and test run. with sqlite 64 bit pharo > 5 crash running test. I think the crash might have to do with the 64 bit library, Pharo being 32 bit won't be able to bind it. Regards! Esteban A. Maringolo

June 5, 2016

Re: [Pharo-users] [ANN] Glorp-SQLite3 for Pharo 5

by francescoagati

yes with 32 bits is ok. i try to use this tutorial for pharo 4. but some references are changed. http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2015-January/0… NBSQLite3DatabaseAccessor isn't present. i have substitute with DatabaseAccessor. but i have this error unable to connect -- View this message in context: http://forum.world.st/ANN-Glorp-SQLite3-for-Pharo-5-tp4899277p4899308.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 5, 2016