- Pharo-dev - lists.pharo.org

pharo jenkins down

by Camillo Bruni

I triggered a faulty jenkins update (or so), hence http://ci.inria.fr/pharo is currently down... I will look into this evening. sorry for the trouble.

July 8, 2013

Re: [Pharo-dev] SmalltalkHub upgrade!

by Sven Van Caekenberghe

On 08 Jul 2013, at 16:48, Nicolas Petton <petton.nicolas(a)gmail.com> wrote: > Right, I just forgot to update the footer :) It is 2.0! Which is cool, BTW. > Nico > > On Jul 8, 2013, at 4:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 30 Jun 2013, at 16:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> One day you have to write a blog post giving us all some insight in the production details, with some nice numbers and graphs. >> >> BTW, isn't SmalltalkHub running on Pharo 2.0 ? >> >> The Jenkins image that I have does in any case, is that not the deployed one ? >> >> But at the bottom it (still) says "Running Amber 0.9.1 - Pharo 1.4 - Seaside 3.0 - MongoDB 2.0.4". >> >> Sven > > -- > Nicolas Petton > http://www.nicolas-petton.fr > >

July 8, 2013

Re: [Pharo-dev] SmalltalkHub upgrade!

by Nicolas Petton

Right, I just forgot to update the footer :) It is 2.0! Nico On Jul 8, 2013, at 4:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Jun 2013, at 16:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> One day you have to write a blog post giving us all some insight in the production details, with some nice numbers and graphs. > > BTW, isn't SmalltalkHub running on Pharo 2.0 ? > > The Jenkins image that I have does in any case, is that not the deployed one ? > > But at the bottom it (still) says "Running Amber 0.9.1 - Pharo 1.4 - Seaside 3.0 - MongoDB 2.0.4". > > Sven -- Nicolas Petton http://www.nicolas-petton.fr

July 8, 2013

Re: [Pharo-dev] SmalltalkHub upgrade!

by Sven Van Caekenberghe

On 30 Jun 2013, at 16:01, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > One day you have to write a blog post giving us all some insight in the production details, with some nice numbers and graphs. BTW, isn't SmalltalkHub running on Pharo 2.0 ? The Jenkins image that I have does in any case, is that not the deployed one ? But at the bottom it (still) says "Running Amber 0.9.1 - Pharo 1.4 - Seaside 3.0 - MongoDB 2.0.4". Sven

July 8, 2013

Re: [Pharo-dev] MongoTalk: new place on smalltalkhub

by Nicolas Petton

nice! Nico On Jul 8, 2013, at 2:45 PM, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > Hi, > > I've just created a new team for MongoTalk on SmalltalkHub: > > http://www.smalltalkhub.com/#!/~MongoTalkTeam > > The old repo (http://www.smalltalkhub.com/#!/~francois/MongoTalk) will stay just in case some scripts rely on it but you should update to the new repo: > > http://www.smalltalkhub.com/#!/~MongoTalkTeam/mongotalk > > I've created a version 1.5.1 in the Metacello configuration to reflect the repo migration. > Shout at me if I missed something! > > Cheers, > Fa > > (Many thanks to Norbert for pushing the migration ;) -- Nicolas Petton http://www.nicolas-petton.fr

July 8, 2013

Re: [Pharo-dev] [Moose-dev] SourceCity works

by Alexandre Bergel

>> Yes, we are aware of it. We are very fortunate that Ronie is expert in OpenGl and low level stuff. Improving NBOpenGL will definitely be part of our effort. >> > > Any help with improving it is welcome. > Let me know if you need a commit rights to project repo. Thanks! We will need the access, but not right now. We are still learning the system... Alexandre >> >> Le 06-07-2013 Ã 4:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : >> >>> cool! >>> >>> Now pay attention that if you do not invest in the NBOpenGL layer to understand it and make it better >>> you will get frustrated and igor cannot spend time on it. >>> >>> Stef >>> >>> On Jul 4, 2013, at 6:23 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>>> Hi Erwan and all, >>>> >>>> Just to make a few things clear about Roassal 3d vs SourceCity. >>>> >>>> We are currently working on Roassal 3d, which intends to be a nice layer at the top of NBOpenGL and NBXLib to easily create 3d scenes with cubes, lights, camera, interactions, zooming, translucent coloring, clicking/rotating/translating individual elements and so on. Everything that is good for Roassal is equally good for 3D Scene. >>>> >>>> Having a city-like visualization will be one of our first objectives since (i) it is a compelling use of 3D and (ii) it is easy to implement (at least the bases). We started to work on a CityBuilder, to easily create cities from objects and provided metrics. Ideally, it would be great to have SourceCity based on our effort. Not now since we have just started Roassal 3D, but on some point we should merge (this is similar in the 2d World with Mondrian and EyeSee moving from plain Morphic to Roassal). >>>> >>>> Our objective is to offer a great 3d framework to make a truly flying SourceCity. >>>> Does this make sense to you? >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> >>>> On Jul 4, 2013, at 10:47 AM, Erwan Douaille <douailleerwan(a)gmail.com> wrote: >>>> >>>>> https://ci.inria.fr/pharo-contribution/job/SourceCity/ >>>>> >>>>> done >>>>> >>>>> >>>>> 2013/7/4 Camillo Bruni <camillobruni(a)gmail.com> >>>>> >>>>> On 2013-07-04, at 15:35, Erwan Douaille <douailleerwan(a)gmail.com> wrote: >>>>> >>>>>> I updated the ConfigurationOfSourceCity. >>>>>> >>>>>> Gofer new >>>>>> smalltalkhubUser: 'ErwanDouaille' project: 'SourceCity'; >>>>>> configuration; >>>>>> load. >>>>>> ConfigurationOfSourceCity loadBleedingEdge >>>>> >>>>> would it make sense to make a jenkins job for this? >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> >>>>> Douaille Erwan <douaille.erwan(a)gmail.com> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >> > > > > -- > Best regards, > Igor Stasenko. > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 8, 2013

Re: [Pharo-dev] MessageNotUnderstood: ZdcSocketStream>>position

by Sven Van Caekenberghe

On 08 Jul 2013, at 11:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jul 8, 2013, at 11:16 AM, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > >> >> > Is this a knows issues? >> >> Yes, and it is already fixed: >> >> === >> Name: Zinc-HTTP-SvenVanCaekenberghe.372 >> Author: SvenVanCaekenberghe >> Time: 30 June 2013, 9:06:10.101049 pm >> UUID: 98ea090f-27d4-498e-8111-95e954d010a9 >> Ancestors: Zinc-HTTP-SvenVanCaekenberghe.371 >> >> Fixed a typo in ZnStringEntity>>#readFrom: (thanks Paul DeBruicker for reporting the issue) >> === >> >> Basically, #position was sent to the socket stream while it should have been sent to a string stream which is properly positionable. The #position / #position: interface makes little to no sense for streams that do not have their whole content in memory. Then again, certain parser seem to need it. >> >> Super. Thanks for the info. >> > > We should do a merge with the upstreamâ¦. > > Marcus Yes, you are absolutely right. Whenever you are ready: https://pharo.fogbugz.com/f/cases/11089/Update-Zn-Zdc-July-2013 Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

July 8, 2013

MongoTalk: new place on smalltalkhub

by FranÃ§ois Stephany

Hi, I've just created a new team for MongoTalk on SmalltalkHub: http://www.smalltalkhub.com/#!/~MongoTalkTeam The old repo (http://www.smalltalkhub.com/#!/~francois/MongoTalk) will stay just in case some scripts rely on it but you should update to the new repo: http://www.smalltalkhub.com/#!/~MongoTalkTeam/mongotalk I've created a version 1.5.1 in the Metacello configuration to reflect the repo migration. Shout at me if I missed something! Cheers, Fa (Many thanks to Norbert for pushing the migration ;)

July 8, 2013

Re: [Pharo-dev] [Moose-dev] SourceCity works

by Igor Stasenko

On 6 July 2013 18:04, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Yes, we are aware of it. We are very fortunate that Ronie is expert in OpenGl and low level stuff. Improving NBOpenGL will definitely be part of our effort. > Any help with improving it is welcome. Let me know if you need a commit rights to project repo. > Alexandre > > Le 06-07-2013 Ã 4:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : > >> cool! >> >> Now pay attention that if you do not invest in the NBOpenGL layer to understand it and make it better >> you will get frustrated and igor cannot spend time on it. >> >> Stef >> >> On Jul 4, 2013, at 6:23 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >>> Hi Erwan and all, >>> >>> Just to make a few things clear about Roassal 3d vs SourceCity. >>> >>> We are currently working on Roassal 3d, which intends to be a nice layer at the top of NBOpenGL and NBXLib to easily create 3d scenes with cubes, lights, camera, interactions, zooming, translucent coloring, clicking/rotating/translating individual elements and so on. Everything that is good for Roassal is equally good for 3D Scene. >>> >>> Having a city-like visualization will be one of our first objectives since (i) it is a compelling use of 3D and (ii) it is easy to implement (at least the bases). We started to work on a CityBuilder, to easily create cities from objects and provided metrics. Ideally, it would be great to have SourceCity based on our effort. Not now since we have just started Roassal 3D, but on some point we should merge (this is similar in the 2d World with Mondrian and EyeSee moving from plain Morphic to Roassal). >>> >>> Our objective is to offer a great 3d framework to make a truly flying SourceCity. >>> Does this make sense to you? >>> >>> Cheers, >>> Alexandre >>> >>> >>> >>> On Jul 4, 2013, at 10:47 AM, Erwan Douaille <douailleerwan(a)gmail.com> wrote: >>> >>>> https://ci.inria.fr/pharo-contribution/job/SourceCity/ >>>> >>>> done >>>> >>>> >>>> 2013/7/4 Camillo Bruni <camillobruni(a)gmail.com> >>>> >>>> On 2013-07-04, at 15:35, Erwan Douaille <douailleerwan(a)gmail.com> wrote: >>>> >>>>> I updated the ConfigurationOfSourceCity. >>>>> >>>>> Gofer new >>>>> smalltalkhubUser: 'ErwanDouaille' project: 'SourceCity'; >>>>> configuration; >>>>> load. >>>>> ConfigurationOfSourceCity loadBleedingEdge >>>> >>>> would it make sense to make a jenkins job for this? >>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> >>>> Douaille Erwan <douaille.erwan(a)gmail.com> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> > -- Best regards, Igor Stasenko.

July 8, 2013

Re: [Pharo-dev] NativeBoost and lacking string argument/return handling

by Igor Stasenko

On 5 July 2013 17:48, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Jul 5, 2013, at 4:59 , Igor Stasenko wrote: > >> Well, to my thinking , in C 'string' defined as 'a sequence of >> characters (bytes) terminated by zero byte'. > Yeah, except, you know, most/all libraries do not really deal with theoretically pure C strings, and we certainly when passing in "a string" from Smalltalk. > In practice, we're dealing with passing/converting Smalltalk strings to functions expecting a pointer to bytes in a certain encoding. (either null-terminated or with an additional size arg) > >> There is nothing about encoding, because it is related to text, but C >> 'string' can be something else than human-readable text and contain >> anything and used for different purpose. >> >> From that perspective, if strictly following such definition, i do not >> see how you can force encoding to be a mandatory part of it. (except >> from having special encoding, named "NO_ENCODING" ;) > > And from that perspective, any user will *never* create safe bindings to/from anything but ASCII ByteStrings by default. > FFI, meet 1988. > And even those who do, have to jump through an excessive amount of hoops, ref > https://dl.dropboxusercontent.com/u/6751081/Environment.zip > >> >> But sure thing, i am not opposed to having a really nice >> encoding/decoding schemes, which you can easily control. >> >> The caveat is that options is applicable to whole callout's generated code. >> What if i have function which takes 2 arguments: >> - string with utf-8 encoding >> - string with utf-16 encoding >> >> so, you cannot put that in options, because you need to control it on >> a per-argument basis. > > >> >> The only way i see how to do that is same as in NBUTF8StringExample: >> you explicitly designate the type of argument e.g. >> >> void foo(utf8String x, utf16String y) > > No, not for FFI you don't. > Any sane external library will never use different encodings for string parameters to the same method. > In fact, I challenge you to find *any* which doesn't. > i agree. So, what's the plan? Each time user puts 'String' pseudo-type, demand encoding? > Cheers, > Henry -- Best regards, Igor Stasenko.

July 8, 2013