July 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 104837: 50183

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 1048373fd757e078b30df8b6734d8974e685c7ec https://github.com/pharo-project/pharo-core/commit/1048373fd757e078b30df8b6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-07-23 (Thu, 23 Jul 2015) Changed paths: M Refactoring-Critics.package/RBAssignmentInIfTrueRule.class/README.md A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - links/testSetLinkOnPrimitive.st A Reflectivity-Tests.package/ReflectivityExamples.class/instance/examples/examplePrimitiveMethod.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitMethodNode_.st M Reflectivity.package/extension/CompiledMethod/instance/installLink_.st R Ring-Core-Kernel.package/RGDefinition.class/instance/testing types/isAssociation.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50182.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50183.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50182.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50183.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50183 16009 Reflectivity: always compile primitive methods on Link install https://pharo.fogbugz.com/f/cases/16009 16007 remove #isAssociation is RGDefiniton https://pharo.fogbugz.com/f/cases/16007 16010 Fix typos in RBAssignmentInIfTrueRules comment https://pharo.fogbugz.com/f/cases/16010 http://files.pharo.org/image/50/50183.zip

July 23, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50183 Home: https://github.com/pharo-project/pharo-core

July 23, 2015

More woden demos

by Ronie Salgado

Hello, I have been working in making a exporter from blender into a custom JSON format for Woden with support for animations. Here I made a short video: https://www.youtube.com/watch?v=HQpaeDQ3TBM&feature=youtu.be I also made a new shader management system for Woden, so I took the opportunity for adding support for parallax occlusion mapping: https://www.youtube.com/watch?v=fFf7v37j8xg&feature=youtu.be Greetings, Ronie

July 23, 2015

Re: [Pharo-dev] ICLC (was "Edge bundles")

by Craig Latta

Hi Ben-- > > I was at the first International Conference on Live Coding[1] > > instead this year, which happened at the same time. A great > > gathering! I hope there's more overlap between that, ESUG, and the > > International Workshop on Live Programming[2] in the future. > > I would be interested to know your impressions and potential for > Smalltalk here. What is that community's current exposure to > Smalltalk and what are their competing technologies? It's not a competition. Everyone uses what they like, respects each other's choices, and collaboration is high, through messaging technologies like OSC[3]. People are educated about and interested in prior work. It's very inspiring. Regarding Smalltalk in particular, there's a lot of potential. I met many people who are interested in systems that are more dynamic, portable, reflective, persistent, etc. I think recent developments toward running in web browsers are what they find most interesting. You can observe and join the Live Coding Research Network discussions at [4]. thanks, -C [1] http://iclc.livecodenetwork.org [2] https://liveprogramming.github.io/2013 [3] http://opensoundcontrol.org [4] http://lurk.org/groups/lcrn -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

July 22, 2015

Re: [Pharo-dev] xmlwriter change brakes an issuetracker-image test

by Paul DeBruicker

Is there a spec for XML documents and if so what does it say is the correct behavior? I would guess the encoding declaration is optional according to the spec and shouldn't be relied on in the test as being there in default. Probably need to add the encoding explicitly if its required by the consumer of the XML document. Nicolai Hess wrote > change in XMLWriter: > Name: XML-Writer-Core-monty.40 > Author: monty > Time: 15 June 2015, 4:35:12.313879 am > UUID: 632db1a0-b6a6-4686-924e-a9bbb2b843b4 > Ancestors: XML-Writer-Core-monty.39 > > xml declaration writers no longer output "encoding=UTF-8" by default > > But now, CIXMLPublisherTest test fails, the test case expects a result > with "encoding=UTF-8" -- View this message in context: http://forum.world.st/xmlwriter-change-brakes-an-issuetracker-image-test-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 22, 2015

Re: [Pharo-dev] New decompiler

by stepharo

You both did a great job. Thanks for making Pharo a better environment. Stef Le 22/7/15 16:02, ClÃ©ment Bera a Ã©crit : > Just some precision because this is really good work. > > For the past 3 years at least, the existing Decompiler used in Pharo > has not been able to decompile correctly all the methods of the Pharo > image. We proved it by recompiling all the methods using their > decompiled sources: this operation was crashing the image as some > methods were installed but not correct. > > With Kevin's Decompiler, the image can now be recompiled from > decompiled sources, still works fine and all the relevant tests can be > run successfully. Hence all the Pharo methods covered by tests or used > by normal development process are proven to be correctly decompiled. > > Therefore, his Decompiler has proven to be better the the existing one. > > I also believe that his Decompiler is overall simpler to understand, > but software simplicity and readability is always very subjective and > arguable so I let you guys have your own opinion on that matter. > > 2015-07-21 19:09 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>>: > > > > On 21 Jul 2015, at 17:31, Kevin Lanvin <kevin.lanvin(a)inria.fr > <mailto:kevin.lanvin@inria.fr>> wrote: > > > > Hello everyone ! > > > > I've been working for 3 months as an intern in RMoD team to > develop a new decompiler. > > It has been integated today. > > It can decompile a whole image. > > Great work, impressive. > > > The only methods that I can't decompile are Native boost calls > because they are based on arguments names, and the name of > temporaries and arguments are lost when a method is compiled. > > If anyone has an idea about how to fix this, let me know. > > > > Thank you ! > > No, thank you ! > > > Kevin Lanvin > > Sven > > >

July 22, 2015

Re: [Pharo-dev] Bug in Zinc with empty Context Type?

by Mariano Martinez Peck

On Wed, Jul 22, 2015 at 11:48 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Mariano, > > I am pretty sure that 'Content-Type' is a required header that cannot be > empty. I imagined..that's why I said that even if it was "server's fault" .... > It seems to be in an AWS S3 response, which is pretty weird (maybe you > uploaded with an empty one in the first place). > No, the file was not updated by me, but from a financial data provider. Just try: ZnClient new get: ' http://static.quandl.com/end_of_day_us_stocks/ticker_list.csv' > > On the other hand, maybe Zn could be a bit more robust. Yes, I think you should. For example, Curl did work for that very same example. > But what should Zn do in this case ? There is no content type that matches > nil, maybe application/octet-stream (ZnMimeType default) ? > > Yes, that's exactly my workaround: ZnEntityReader >> contentType ^ ((self headers includesKey: 'Content-Type') *and: [ (self headers at: 'Content-Type') isEmpty not]*) ifTrue: [ self headers contentType ] ifFalse: [ ZnMimeType applicationOctetStream ] Probably you can make that prettier :) > Sven > > > On 22 Jul 2015, at 16:15, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > Hi, > > > > I am using Zinc to get the contents of a file. The code works correct in > GemStone (because I think it uses a different/older) version but in Pharo > it throws an error in: > > > > ZnHeaders >> contentType > > ^ ZnMimeType fromString: (self headers at: 'Content-Type') > > > > The error there is in the #fromString: since " (self headers at: > 'Content-Type')" answers an empty string. > > The error inside #fromString is in this line: > > > > sub := aString copyFrom: main size + 2 to: endOfSub. > > > > that fails of course since 'aString' is an empty string. > > > > Curl shows indeed that the url I am getting has an empty content type > defined: > > > > < HTTP/1.1 200 OK > > < x-amz-id-2: > eBymTYeSNAPTsgOYDvpbqj/gIPcPpuSb6F0ca/zVjLUG+P2hLZJy/IbU+4MX42sW > > < x-amz-request-id: F82747AD31A40F4E > > < Date: Wed, 22 Jul 2015 14:02:00 GMT > > < Last-Modified: Tue, 21 Jul 2015 20:42:44 GMT > > < ETag: "a9fc27157bca2863a58c331e0eae27fb" > > < Content-Type: > > < Content-Length: 437013 > > < Server: AmazonS3 > > > > So...while it may be "server's fault" because it may be doing something > wrong, is still need to get it. I haven't found any workaround in Zinc that > it wasn't changing code. > > > > I am fine with changing code / override if this is a bug and will be > fixed later. But if there is a setting or something I would be glad to know > it. > > > > Thanks, > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

July 22, 2015

Re: [Pharo-dev] Bug in Zinc with empty Context Type?

by Sven Van Caekenberghe

Hi Mariano, I am pretty sure that 'Content-Type' is a required header that cannot be empty. It seems to be in an AWS S3 response, which is pretty weird (maybe you uploaded with an empty one in the first place). On the other hand, maybe Zn could be a bit more robust. But what should Zn do in this case ? There is no content type that matches nil, maybe application/octet-stream (ZnMimeType default) ? Sven > On 22 Jul 2015, at 16:15, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Hi, > > I am using Zinc to get the contents of a file. The code works correct in GemStone (because I think it uses a different/older) version but in Pharo it throws an error in: > > ZnHeaders >> contentType > ^ ZnMimeType fromString: (self headers at: 'Content-Type') > > The error there is in the #fromString: since " (self headers at: 'Content-Type')" answers an empty string. > The error inside #fromString is in this line: > > sub := aString copyFrom: main size + 2 to: endOfSub. > > that fails of course since 'aString' is an empty string. > > Curl shows indeed that the url I am getting has an empty content type defined: > > < HTTP/1.1 200 OK > < x-amz-id-2: eBymTYeSNAPTsgOYDvpbqj/gIPcPpuSb6F0ca/zVjLUG+P2hLZJy/IbU+4MX42sW > < x-amz-request-id: F82747AD31A40F4E > < Date: Wed, 22 Jul 2015 14:02:00 GMT > < Last-Modified: Tue, 21 Jul 2015 20:42:44 GMT > < ETag: "a9fc27157bca2863a58c331e0eae27fb" > < Content-Type: > < Content-Length: 437013 > < Server: AmazonS3 > > So...while it may be "server's fault" because it may be doing something wrong, is still need to get it. I haven't found any workaround in Zinc that it wasn't changing code. > > I am fine with changing code / override if this is a bug and will be fixed later. But if there is a setting or something I would be glad to know it. > > Thanks, > > > -- > Mariano > http://marianopeck.wordpress.com

July 22, 2015

Bug in Zinc with empty Context Type?

by Mariano Martinez Peck

Hi, I am using Zinc to get the contents of a file. The code works correct in GemStone (because I think it uses a different/older) version but in Pharo it throws an error in: ZnHeaders >> contentType ^ ZnMimeType fromString: (self headers at: 'Content-Type') The error there is in the #fromString: since " (self headers at: 'Content-Type')" answers an empty string. The error inside #fromString is in this line: sub := aString copyFrom: main size + 2 to: endOfSub. that fails of course since 'aString' is an empty string. Curl shows indeed that the url I am getting has an empty content type defined: < HTTP/1.1 200 OK < x-amz-id-2: eBymTYeSNAPTsgOYDvpbqj/gIPcPpuSb6F0ca/zVjLUG+P2hLZJy/IbU+4MX42sW < x-amz-request-id: F82747AD31A40F4E < Date: Wed, 22 Jul 2015 14:02:00 GMT < Last-Modified: Tue, 21 Jul 2015 20:42:44 GMT < ETag: "a9fc27157bca2863a58c331e0eae27fb" *< Content-Type:* < Content-Length: 437013 < Server: AmazonS3 So...while it may be "server's fault" because it may be doing something wrong, is still need to get it. I haven't found any workaround in Zinc that it wasn't changing code. I am fine with changing code / override if this is a bug and will be fixed later. But if there is a setting or something I would be glad to know it. Thanks, -- Mariano http://marianopeck.wordpress.com

July 22, 2015

Re: [Pharo-dev] New decompiler

by ClÃ©ment Bera

Just some precision because this is really good work. For the past 3 years at least, the existing Decompiler used in Pharo has not been able to decompile correctly all the methods of the Pharo image. We proved it by recompiling all the methods using their decompiled sources: this operation was crashing the image as some methods were installed but not correct. With Kevin's Decompiler, the image can now be recompiled from decompiled sources, still works fine and all the relevant tests can be run successfully. Hence all the Pharo methods covered by tests or used by normal development process are proven to be correctly decompiled. Therefore, his Decompiler has proven to be better the the existing one. I also believe that his Decompiler is overall simpler to understand, but software simplicity and readability is always very subjective and arguable so I let you guys have your own opinion on that matter. 2015-07-21 19:09 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 21 Jul 2015, at 17:31, Kevin Lanvin <kevin.lanvin(a)inria.fr> wrote: > > > > Hello everyone ! > > > > I've been working for 3 months as an intern in RMoD team to develop a > new decompiler. > > It has been integated today. > > It can decompile a whole image. > > Great work, impressive. > > > The only methods that I can't decompile are Native boost calls because > they are based on arguments names, and the name of temporaries and > arguments are lost when a method is compiled. > > If anyone has an idea about how to fix this, let me know. > > > > Thank you ! > > No, thank you ! > > > Kevin Lanvin > > Sven > > >

July 22, 2015