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

Re: [Pharo-dev] The Smalltalk Renaissance Program

by horrido

Our Facebook page needs some TLC (2 Likes so far; looks rather lonely). PLEASE, go there and "Like" it! -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797643.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 2, 2015

Re: [Pharo-dev] [Vm-dev] New Cog VMs available

by Douglas McPherson

Thanks Eliot! Happy New Year to you and everyone. ARMv6 stack and stack/spur VMs updated accordingly. (These work on v7 alsoâ¦ v7 specific versions without fast BitBlt to follow). Doug > On Jan 1, 2015, at 20:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > ...at http://www.mirandabanda.org/files/Cog/VM/VM.r3205/ <http://www.mirandabanda.org/files/Cog/VM/VM.r3205/>. > > Happy New Year! > > CogVM source as per VMMaker.oscog-eem.1008/r3205 > > Send cannotReturn for sideways return attemps when there's an unwind-protect. > Old code would erroneously answer unwind-protect even if home could'nt be found. > > e.g. This should raise cannot return: > > | b | > b := [ ^ 42 ]. > [ [b value] ensure: [1] ] fork. > Processor yield > > just as this does: > > | b | > b := [ ^ 42 ]. > [ b value ] fork. > Processor yield > > Speed up non-local return processing by using the fact that 98% of the time > returns are within the same page. The search for the home context following > finding an unwind is unnecessary iff the home is married and on the same page. > > Refactor commonReturn to eiminate CoInterpreter's version, moving the > divergence into maybeReturnToMachineCodeFrame. > > Ensure search for home through the block's closure uses followField:ofObject:. > > (related) Revisit the Sista bug fix for followed contexts during scavenging in > VMMaker.oscog-eem.913 of 24 October 2014. Split isWidowedContext: into a more > careful version, isWidowedContextDuringGC: for use only during scavenging. > > Win32: > Nuke obsolete RCS vrsion info > > Spur: > Fix argument count slips in three primitives. > Check for sufficient memory in two-way become. > > All: > Fix checking of boolean arg in primitiveArrayBecomeOneWayCopyHash. > > Make primitiveSlotAt[Put] cope with non-pointer objects. > > Change the pixel-touch-pixel prim to allow LPI arguments for the color values > > Update the ScratchPlugin bilinear scaling prim to include the correct alpha channel value for non-transparent output pixels. > > No longer build or upload the Newspeak V3 VMs, now superseded by Spur. > > Use the gcc/clang built-ins for CAS and atomic increment if available. > > -- > best, > Eliot

Jan. 2, 2015

Re: [Pharo-dev] The Smalltalk Renaissance Program

by Sebastian Sastre

> On Jan 2, 2015, at 4:18 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > * Small business application ( not helloworld ) should be say a 1-3 hr work with documentation given. Rails promised that hiding its complexity to user discovery but by then the user is hooked on enough to provide his inputs / improve the framework. I liked the Teapot, Amber need to push more around that kernel to make it scale upto creating a full application framework deployable in 3 hrs. This is the kind of thing Iâm working on here <https://github.com/flow-stack/flow> which uses Amber at the frontend and Pharo at the backend. I would be very interested in hearing your review. Iâm currently working in making installation easier to lower the initial friction. Also, if you have ideas on what is needed to get to that 1 to 3h prototype goal, you are welcome to share your thoughts in the input/feedback column of this trello board: https://trello.com/b/oQ17lPpV/flow <https://trello.com/b/oQ17lPpV/flow>

Jan. 2, 2015

Re: [Pharo-dev] HandMorph.EventStats

by Marcus Denker

On Fri, Jan 2, 2015 at 4:51 PM, Ben Coman <btc(a)openinworld.com> wrote: > > Looking at HandMorph>>logEventStats: > this is the only method to reference EventStats variable. > > Should we zero these values as part of release process? > > Yes, and there needs to be a preferences to not record, and it should be off by default. -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Jan. 2, 2015

HandMorph.EventStats

by Ben Coman

Looking at HandMorph>>logEventStats: this is the only method to reference EventStats variable. Should we zero these values as part of release process? cheers -ben

Jan. 2, 2015

Re: [Pharo-dev] Is immutability on Pharo's roadmap?

by Sebastian Sastre

great! thanks for the update from mobile > On 02/01/2015, at 10:03, Ben Coman <btc(a)openInWorld.com> wrote: > > And this one... > > http://lists.squeakfoundation.org/pipermail/vm-dev/2012-May/010719.html > > So the answer your questions it seems is: beneficial, yes & yes. > >> On Fri, Jan 2, 2015 at 4:22 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >> did you see this thread a while back: >> >> http://forum.world.st/Should-literals-be-immutable-td4786938.html >> >> >> >> sebastian(a)flowingconcept.com wrote >> > Sorry for the naive question but Iâm seeing an avalanche of interest in >> > functional programming and many there uses immutability as foundation. So >> > I wonder whatâs our position on that way of working? >> > >> > Does Pharo have immutability in its roadmap at any point? >> > >> > Do you find it valuable? >> >> >> >> >> >> -- >> View this message in context: http://forum.world.st/Is-immutability-on-Pharo-s-roadmap-tp4797588p4797600.… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Jan. 2, 2015

Re: [Pharo-dev] Cog in the cloud

by Ben Coman

> Eliot Miranda wrote: > >> >> - what key economic and managerial benefits accrue from this >> configuration? >> > > I found this... https://medium.com/@darrenrush/after-docker-unikernels-and-immutable-infras…

Jan. 2, 2015

Re: [Pharo-dev] Is immutability on Pharo's roadmap?

by Ben Coman

And this one... http://lists.squeakfoundation.org/pipermail/vm-dev/2012-May/010719.html So the answer your questions it seems is: beneficial, yes & yes. On Fri, Jan 2, 2015 at 4:22 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > did you see this thread a while back: > > http://forum.world.st/Should-literals-be-immutable-td4786938.html > > > > sebastian(a)flowingconcept.com wrote > > Sorry for the naive question but Iâm seeing an avalanche of interest in > > functional programming and many there uses immutability as foundation. So > > I wonder whatâs our position on that way of working? > > > > Does Pharo have immutability in its roadmap at any point? > > > > Do you find it valuable? > > > > > > -- > View this message in context: > http://forum.world.st/Is-immutability-on-Pharo-s-roadmap-tp4797588p4797600.… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Jan. 2, 2015

Re: [Pharo-dev] The Smalltalk Renaissance Program

by S Krish

*Wishes for a great new year for Pharo.. !..* Subjective topics are the easiest to waste one's effort on, though are essential in their own way, if we restrain ourselves. Pharo to me is headed in the right direction with the right evangelists at its core. There should not be a dilution to it in any pursuit. a) PR and spreading the awareness is important to a pursuit of increasing usage of the technology but not essential. b) For a software platform ( again I say Pharo / Smalltalk is a platform not a langauge ), it is question of : Success is not from Pharo Platform per se but from its* usable frameworks:* * Seek success organically, evolve to be the best fit for enterprise programming, this can be through any of Seaside, Teapot+Zn, Glamour toolkit, Jun, Open CL/R other interfaces, R Pi custom OS, etc.. or as in mega framework like OpenStack in Pharo weaving in existing elements of the mega framework for now.. et als. Make the framework use simple, scalable, flexible that it is viral in its growth for the programmers. * Small business application ( not helloworld ) should be say a 1-3 hr work with documentation given. Rails promised that hiding its complexity to user discovery but by then the user is hooked on enough to provide his inputs / improve the framework. I liked the Teapot, Amber need to push more around that kernel to make it scale upto creating a full application framework deployable in 3 hrs. *Pharo Platform:* * The platform offers stable and guaranteed behavior across fundamentals of operations (all of CPU/ Mem/ OS resource use et als ), security specially that ensures programmers can easily convince the CEO/CTO's to allow their pet projects to be integrated. Gaps will exist and programmers will fulfill it and grow the frameworks. Make the users feel as both "winners" and "owners" in using the frameworks. Yes we need visionaries to lead those frameworks. * Make it as modular as possible to be able to use it just plain commandline, with or without UI and its varied tools but with any of the packages with dependencies that are well structured and easily updateable. * The platform if it targets the enterprise will have to target enterprise interfaces viz: DBMS, MQ, WS , deployment through easy integration with Apache webserver or other common platforms. This is an incremental goal driven by state of Pharo now and overal ecosystem of its platform progressing together. *PR:* * Seek to push what you have to others through PR, at best this can only be adjunct to the above, will probably yield some benefit but will not be the raison-de-etre of the success of a product. Infact one part of PR I believe works ( not something many intellectuals prefer) create sub-forums/ sub-committees and make more and more people be part of it. * I would much rather prefer having a website that showcases each enterprise use like in Seaside the web application framework. But what the seaside site lacks is a complete brief on deploying a web app end to end with DBMS integration, easy css, js, et als integrated in 1 - 3 hrs, fairly customized to my first prototype I require. Similar focussed sites should exist that can be simple 1-2-3 instruction for the helloworld and scale up quickly within a day to a workable app customized for requirement. Most important leverage as much of pre-existing skills as in HTML, CSS, JS, MQ, DBMS, ORM et als.. rather than create a new learning curve of the developer. The kernel should be a killer feature as in Seaside/ Teapot but they need to keep the continuum.. while taking the high ground Let me put my hands on some of these efforts and then talk more. I am greatly interested in pushing Pharo to enterprise use atleast for a personal pursuit, let this new year resolution be to see that happens before the year runs out. On Fri, Jan 2, 2015 at 10:01 AM, horrido <horrido.hobbies(a)gmail.com> wrote: > Smalltalk isn't the ultimate language for me, either. I happen to like Go a > lot. And it's conceivable that someone may come up with another truly great > programming language in the future. >

Jan. 2, 2015

Re: [Pharo-dev] Is immutability on Pharo's roadmap?

by Paul DeBruicker

did you see this thread a while back: http://forum.world.st/Should-literals-be-immutable-td4786938.html sebastian(a)flowingconcept.com wrote > Sorry for the naive question but Iâm seeing an avalanche of interest in > functional programming and many there uses immutability as foundation. So > I wonder whatâs our position on that way of working? > > Does Pharo have immutability in its roadmap at any point? > > Do you find it valuable? -- View this message in context: http://forum.world.st/Is-immutability-on-Pharo-s-roadmap-tp4797588p4797600.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 2, 2015