- Pharo-users - lists.pharo.org

Re: [Pharo-users] Problem compiling method source - genPushLiteral: out of range

by Marcus Denker

> On 18 Aug 2017, at 11:34, Patrick Scherer <patrick.scherer(a)hrworks.de> wrote: > > Hello everyone, > > I'm trying to move some of our code from VA Smalltalk over to Pharo using a self-made importer and have encountered the following issue I need help with: > > A few of our methods are very large in size. For example, we have a method that creates a huge Dictionary with specific keys and values on startup and stores it in a class variable for immediate access. > This method works fine in VA Smalltalk, but if I attempt to compile the same source code in Pharo (programmatically or via copy paste using the interface) I'm getting 'Error: genPushLiteral: index index 256 is out of range 0 to 255' in OpalEncoderForV3PlusClosures. I'm getting the same error for some other methods. > > If I understand this correctly, the method simply exceeds the maximum number of literals, but it works fine in VA Smalltalk. Is there a way to increase this limit or bypass this issue without having to rework our implementation? > Hello, Can you try to change (in the preferences) the Bytecode Backend to âSistaV1â (this is the new byte code set that will be the default at some point in the future). Marcus

Aug. 18, 2017

Re: [Pharo-users] [Ann] Blog entry about using Pharo / Smalltalk to build a bot

by sergio ruiz

Oh! I like your approach.. Let me quickly clarify my situation. In that section of the article, I was referring to my workplace. In my case, no one else in the dev department knows smalltalk. In a great many workplaces, devs donât really want to learn a new language / framework without going off to a developer summer camp or something like that. I have found that once a developer gets to a certain level of competence, they can quickly (in a weekend?) get up to speed on the use of a new language / framework to get their project done. For a long time, I felt the sting of the âmost popular language listsâ as companies wanted to start all projects in PHP so that if the senior devs moved on, they could just hire some kids âcheap, just out of schoolâ to work on the project. i do think there are lots of things about to change Pharoâs place in the world, especially the Pharo MOOC.. there was one claim you made in that post that got me thinking ""No one else knows Smalltalk."Â So I wonder how many developers amount to "no one". ---- peace, sergio photographer, journalist, visionary Public Key:Â http://bit.ly/29z9fG0 #BitMessageÂ BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Aug. 18, 2017

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Marcus Denker

> On 18 Aug 2017, at 13:08, Tim Mackinnon <tim(a)testit.works> wrote: > > Thanks Marcus - and definitely we all appreciate that its holiday season and that a lot of this is driven by community and people donating their free time. > > Iâm still a bit unclear on the moving parts. To paraphrase what you have said: > > We start each yearly cycle with a X.0 new release. Then there may be point releases 6.1, 6.2 etc where there is a breaking change (typically a new VM I guess - but is there anything else that would cause a .x release?). > > Then there are âhot fixesâ that causes an image number change (these have worked there way through the CI, as it triggered a new build)? The implication is then that what I download from Pharo.org <http://pharo.org/> is the last point release, No, the download is always the latest (with all accepted fixes integrated). > but then I can go and find a newer image âhot fixâ if I want some of the latest more minor fixes (and I guess this then answers m .x question above - as I guess that if there was a major bug in the image it might also trigger a new point release so that new users would get that fix when downloading from pharo.org <http://pharo.org/>?) > The problem is that doing a release 6.1 takes half a day of work. We could improve that, but then with Pharo7 all this changed anyway, so we will not improve this process. (and not do many releases of this kind for Pharo6). > So a reasonably active Pharo user (but not a more bleeding edge new release user) should typically download the latest image every month to stay current? > Normally you have a CI that builds from the latest pharo image + the latest commit from your repo and you start with that all couple of days/weeks (This is important to make sure that you have a reproduce build, too). > We should encourage more seasoned users to also try a leading edge point release, and apply the latest hot fix image particularly in the latter part of year when we are trying to stabilise for the next release cycle. And then there are the instructions about taking the next leap for contributing backâ¦ > > Is this right? Not really. *all* fixes that go into the stable release go into the development release, too. So the releases of stable Pharo6 have not much todo with Pharo7, no need to run a special Pharo6 when we stabilize Pharo7. Here it is important that people use Pharo7. Keep in mind that we try to do active development only in the development branch, so we talk about 20-30 fixes in total, many many are not really that important or are just important for those who ran into them. So we should not be too complex about itâ¦ it worked fine like this the last years. Marcus

Aug. 18, 2017

Re: [Pharo-users] ZnConstants class>>#httpStatusCodes and cloudflare

by Sven Van Caekenberghe

Hi Holger, It is probably not a good idea to be too strict here. I committed the following to #bleedingEdge === Name: Zinc-HTTP-SvenVanCaekenberghe.465 Author: SvenVanCaekenberghe Time: 18 August 2017, 2:11:25.092807 pm UUID: da9ed1c3-6713-0d00-bd88-7a0d0e6057cd Ancestors: Zinc-HTTP-SvenVanCaekenberghe.464 Allow for non-standard, not-predefined HTTP status line codes as long as they are between 100 and 599 === Name: Zinc-Tests-SvenVanCaekenberghe.240 Author: SvenVanCaekenberghe Time: 18 August 2017, 2:11:44.677301 pm UUID: ad74fcc4-6713-0d00-bd89-fc2d0e6057cd Ancestors: Zinc-Tests-SvenVanCaekenberghe.239 Allow for non-standard, not-predefined HTTP status line codes as long as they are between 100 and 599 === Sven > On 18 Aug 2017, at 11:44, Holger Freyther <holger(a)freyther.de> wrote: > > Hi, > > I am currently using ZnClient to fetch data from a service behind "cloudflare" and sometimes the real/origin backend is unreachable/fails. Cloudflare has added additional[1] 5XX codes and ZnStatusLine>>#code: will signal an ZnUnknownHttpStatusCode because of that. > > I wonder how ZnClient should deal with these errors? IIRC the HTTP RFC specifies error classes and without knowing what "525" means one can know that the request was not successful and that the server is at "fault"? > > Should ZnStatusLine handle an unknown code gracefully? E.g. >>#reason: seems to do that already? > > > have a nice weekend > > holger > > [1] https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#Cloudflare

Aug. 18, 2017

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Tim Mackinnon

Thanks Marcus - and definitely we all appreciate that its holiday season and that a lot of this is driven by community and people donating their free time. Iâm still a bit unclear on the moving parts. To paraphrase what you have said: We start each yearly cycle with a X.0 new release. Then there may be point releases 6.1, 6.2 etc where there is a breaking change (typically a new VM I guess - but is there anything else that would cause a .x release?). Then there are âhot fixesâ that causes an image number change (these have worked there way through the CI, as it triggered a new build)? The implication is then that what I download from Pharo.org <http://pharo.org/> is the last point release, but then I can go and find a newer image âhot fixâ if I want some of the latest more minor fixes (and I guess this then answers m .x question above - as I guess that if there was a major bug in the image it might also trigger a new point release so that new users would get that fix when downloading from pharo.org <http://pharo.org/>?) So a reasonably active Pharo user (but not a more bleeding edge new release user) should typically download the latest image every month to stay current? We should encourage more seasoned users to also try a leading edge point release, and apply the latest hot fix image particularly in the latter part of year when we are trying to stabilise for the next release cycle. And then there are the instructions about taking the next leap for contributing backâ¦ Is this right? Tim > On 18 Aug 2017, at 08:56, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> What I think would have been good is to list all the updates that where done between >> releasing 6.0 and 6.1 *as part of the changelog* of 6.1 (even though they were already >> in the image that you got a minute before Pharo6.1 was released, as they where released as >> hot fixes before). >> > > The changelog of things done between releasing 6.0 and the release of 6.1: > > 20262 Update Iceberg to 0.5.4 > https://pharo.fogbugz.com/f/cases/20262 > > 20268 update iceberg v0.5.5 > https://pharo.fogbugz.com/f/cases/20268 > > 20226 TabMorph should use stepping mechanism for animating background building > https://pharo.fogbugz.com/f/cases/20226 > > 20238 Run out of memory the image hangs without out of memory warning > https://pharo.fogbugz.com/f/cases/20238 > > 20218 Master branch (Pharo 6) needs to be safely merged into development branch (Pharo 7). > https://pharo.fogbugz.com/f/cases/20218 > > 20187 Request use of block in certain methods > https://pharo.fogbugz.com/f/cases/20187 > > 20188 Request representation of integer literal without float exponent > https://pharo.fogbugz.com/f/cases/20188 > > 20182 Extra dot in literal array > https://pharo.fogbugz.com/f/cases/20182 > > 18760 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions > https://pharo.fogbugz.com/f/cases/18760 > > 20186 Request removal of extra statement separators (dot) > https://pharo.fogbugz.com/f/cases/20186 > > 20185 Request pipe after block argments > https://pharo.fogbugz.com/f/cases/20185 > > 20183 TraitDescription>>fileOutLocalMethodsInCategory:on: method temp var name overlap > https://pharo.fogbugz.com/f/cases/20183 > > 20184 Request space between argument and selector in StdioStream>>next: > https://pharo.fogbugz.com/f/cases/20184 > > 20167 Regression with PNGReaderWriter in P6 > https://pharo.fogbugz.com/f/cases/20167 > > 20198 inner structure access does not work on multiple architecture > https://pharo.fogbugz.com/f/cases/20198 > > 20110 AllocationTest>>#testOutOfMemorySignal not well suited to 64-bit > https://pharo.fogbugz.com/f/cases/20110 > > 20096 Add script pragma to SpaceTally>>printSpaceAnalysis > https://pharo.fogbugz.com/f/cases/20096 > > 20174 In the debug halo of a morph: clicking on "inspect morph" and "explore morph" bring up the same window. > https://pharo.fogbugz.com/f/cases/20174 > > 20093 Missing source stamp makes changes hard to view > https://pharo.fogbugz.com/f/cases/20093 > > 20148 transforming deprecations should take #showWarning into account > https://pharo.fogbugz.com/f/cases/20148 > > 20146 ZnHTTPSTests>>#testGetPharoVersion started to fail > https://pharo.fogbugz.com/f/cases/20146 > > > >

Aug. 18, 2017

Re: [Pharo-users] Encoding Login information in your image (safely)

by Pierce Ng

On Wed, Aug 16, 2017 at 02:24:15PM -0300, Esteban A. Maringolo wrote: > My solution in the cases where I was worried about a config file leak > was to mitigate the risk, by using symmetric encryption algorithms, > where the shared secret is split in two different strings and > concatenated at runtime. The image, in turn holds the encryption key Take a look at SpsSplitPasswordStore, which is a simple secret splitter. http://ss3.gemtalksystems.com/ss/SpsSplitPasswordStore.html/ http://samadhiweb.com/blog/2013.08.11.splitpasswordstore.html Can be adapted to encrypt/decrypt the secret, with the cipher key also split, perhaps with one part stored in the image and another part fetched online from somewhere. I haven't touched the code in a while, but the Pharo 5 image that runs my blog is using this for the RFBServer passwords. Pierce

Aug. 18, 2017

Re: [Pharo-users] Problem compiling method source - genPushLiteral: out of range

by Henrik Sperre Johansen

The limitation is inherit in the object format/ instruction set, you can find some previous discussions at http://forum.world.st/Max-source-method-length-Max-string-length-Max-change… and http://forum.world.st/More-than-256-literals-referenced-td4676669.html#a467… One alternative is to change the compiler to create a literal array to hold all literals > 255 and rewrite accesses to indexes above 254 as something like genPushLiteral: 255 pushLiteral #at: pushConst: X messageSend , but as long as we're talking about a single digit number of cases, and not translating 200+ UI specs, it is probably a lot easier (albeit, maybe a little slower) to rewrite the code in a way which works in both dialects without using a large number of literals, say: MyClass class >> #initializeStaticVals dict := Dictionary new. initializerPairs := #( Key1 2 Key2 4 ). 1 to: initializerPairs size by: 2 do: [:ix | dict at: (initializerPairs at: ix) put: (initializerPairs at: ix +1)]. MyClassVar := dict. (Haven't seen a support layer package for VA, sorry) Cheers, Henry -- View this message in context: http://forum.world.st/Problem-compiling-method-source-genPushLiteral-out-of… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 18, 2017

ZnConstants class>>#httpStatusCodes and cloudflare

by Holger Freyther

Hi, I am currently using ZnClient to fetch data from a service behind "cloudflare" and sometimes the real/origin backend is unreachable/fails. Cloudflare has added additional[1] 5XX codes and ZnStatusLine>>#code: will signal an ZnUnknownHttpStatusCode because of that. I wonder how ZnClient should deal with these errors? IIRC the HTTP RFC specifies error classes and without knowing what "525" means one can know that the request was not successful and that the server is at "fault"? Should ZnStatusLine handle an unknown code gracefully? E.g. >>#reason: seems to do that already? have a nice weekend holger [1] https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#Cloudflare

Aug. 18, 2017

Problem compiling method source - genPushLiteral: out of range

by Patrick Scherer

Hello everyone, I'm trying to move some of our code from VA Smalltalk over to Pharo using a self-made importer and have encountered the following issue I need help with: A few of our methods are very large in size. For example, we have a method that creates a huge Dictionary with specific keys and values on startup and stores it in a class variable for immediate access. This method works fine in VA Smalltalk, but if I attempt to compile the same source code in Pharo (programmatically or via copy paste using the interface) I'm getting '*Error: genPushLiteral: index index 256 is out of range 0 to 255*' in OpalEncoderForV3PlusClosures. I'm getting the same error for some other methods. If I understand this correctly, the method simply exceeds the maximum number of literals, but it works fine in VA Smalltalk. Is there a way to increase this limit or bypass this issue without having to rework our implementation? Offtopic: Does anybody if there is a package which adds a support layer for imported VA Smalltalk code? I know there is one for Pharo->VA on VASTGoodies but I couldn't find one for the other way around. Kind regards, Patrick Scherer

Aug. 18, 2017

Re: [Pharo-users] Parser failure on FFI pragmas declaration in Pharo 5

by Denis Kudriashov

> > @Esteban: Would you accept a change to the FFI-Pharo5Compat to not use the > currentScope variable/reduce error checking? Or would you accept it in a > FFI-Pharo6Compat package? > I think it would help to be able to load the Nacl code in Pharo6 and then > fix it? But you can just switch default compiler. Is not works for you? 2017-08-18 10:20 GMT+02:00 Holger Freyther <holger(a)freyther.de>: > > > On 17. Aug 2017, at 19:37, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > Hey! > > > Yes. > > > > Also simple solution can be to override compiler of problem classes to > return old compiler. > > > > I know it is better to rewrite code but it can be not simple task when > there are a lot of ffi-methods. > > > I ran into this problem with the wonderful (as it had a SHA256 > implementation) NaCl bindings. > > > Pharo5: > * RBParser still has the currentScope variable and can import it > * Syntax highlighting ends in an exception (which I disabled) > > Pharo6: > * RBParser doesn't have currentScope anymore so I patched it out > * Syntax highlighting seems to work fine > > > @Esteban: Would you accept a change to the FFI-Pharo5Compat to not use the > currentScope variable/reduce error checking? Or would you accept it in a > FFI-Pharo6Compat package? > > I think it would help to be able to load the Nacl code in Pharo6 and then > fix it? > > > what do you think? > > holger >

Aug. 18, 2017