May 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Iceberg

by Esteban Lorenzano

are you trying VM latest? because you should use the stable now :) I explain: I updated the latest VM to libgit2 0.25.1. While this works on most of my cases, I spotted this problem too. cheers, Esteban > On 7 May 2017, at 18:40, Myroslava Romaniuk <romaniuk(a)ucu.edu.ua> wrote: > > I am also trying to clone a repository and for me the command causes the following error: LGit_GIT_ERROR: error authenticating: failed connecting agent. I am using the latest image (60482) on Win 7 (64 bit). > > On 7 May 2017 at 19:06, Elhamer <abdelkhalekdev(a)gmail.com <mailto:abdelkhalekdev@gmail.com>> wrote: > EstebanLM wrote > >>Yes, there is a bug now in iceberg (I will fix it soon), for now you can > go with: > > > >>IceRepository defaultBackendType: #IceLibgitLocalRepository. > > > This actually causes an Assertion failure, then a total crash: > --------------------------- > Microsoft Visual C++ Runtime Library > --------------------------- > Assertion failed! > > Program: ... > File: e:/workspace/PharoVM-spur32/Architecture.../remote.c > Line: 430 > > Expression: out && repo && name > > For information on how your program can cause an assertion > failure, see the Visual C++ documentation on asserts > > (Press Retry to debug the application - JIT must be enabled) > --------------------------- > Abort Retry Ignore > --------------------------- > > I am using the image #60480 on a Windows 10 64bits OS > > > > > > > -- > View this message in context: http://forum.world.st/Iceberg-tp4945776p4945804.html <http://forum.world.st/Iceberg-tp4945776p4945804.html> > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > -- > Ð Ð¿Ð¾Ð²Ð°Ð³Ð¾Ñ, > ÐÐ¸ÑÐ¾ÑÐ»Ð°Ð²Ð° Ð Ð¾Ð¼Ð°Ð½ÑÐº.

May 7, 2017

Re: [Pharo-dev] Anyone meeting up night before Pharo Days (17th?)

by Stephan Eggermont

On 06/05/17 12:58, Tim Mackinnon wrote: > Hi guys - I managed to get a âweeknight passâ so that I can come to > Pharo days and try and catch up with all the progress you have made. > > Iâm taking a Eurostar on Wed night (17th) and wondering if anyone is > meeting up the night before on the 17th? I donât arrive until 8:30 - > but maybe some of you are having some post supper drinks somewhere? Yes, good idea. I'll arrive with a TGV from CDG at 21:11 > I have booked a hotel near the venue, but Iâm thinking that I may > change it, to somewhere in town as I think it might make more sense > as Iâm sure folks may end up eating in town anyway. I haven't booked a hotel yet. I'll go for in-town. Stephan

May 7, 2017

Re: [Pharo-dev] Iceberg

by Myroslava Romaniuk

I am also trying to clone a repository and for me the command causes the following error: *LGit_GIT_ERROR: error authenticating: failed connecting agent*. I am using the latest image (60482) on Win 7 (64 bit). On 7 May 2017 at 19:06, Elhamer <abdelkhalekdev(a)gmail.com> wrote: > EstebanLM wrote > >>Yes, there is a bug now in iceberg (I will fix it soon), for now you can > go with: > > > >>IceRepository defaultBackendType: #IceLibgitLocalRepository. > > > This actually causes an Assertion failure, then a total crash: > --------------------------- > Microsoft Visual C++ Runtime Library > --------------------------- > Assertion failed! > > Program: ... > File: e:/workspace/PharoVM-spur32/Architecture.../remote.c > Line: 430 > > Expression: out && repo && name > > For information on how your program can cause an assertion > failure, see the Visual C++ documentation on asserts > > (Press Retry to debug the application - JIT must be enabled) > --------------------------- > Abort Retry Ignore > --------------------------- > > I am using the image #60480 on a Windows 10 64bits OS > > > > > > > -- > View this message in context: http://forum.world.st/Iceberg- > tp4945776p4945804.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Ð Ð¿Ð¾Ð²Ð°Ð³Ð¾Ñ, ÐÐ¸ÑÐ¾ÑÐ»Ð°Ð²Ð° Ð Ð¾Ð¼Ð°Ð½ÑÐº.

May 7, 2017

Re: [Pharo-dev] Iceberg

by Elhamer

EstebanLM wrote >>Yes, there is a bug now in iceberg (I will fix it soon), for now you can go with: > >>IceRepository defaultBackendType: #IceLibgitLocalRepository. This actually causes an Assertion failure, then a total crash: --------------------------- Microsoft Visual C++ Runtime Library --------------------------- Assertion failed! Program: ... File: e:/workspace/PharoVM-spur32/Architecture.../remote.c Line: 430 Expression: out && repo && name For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts (Press Retry to debug the application - JIT must be enabled) --------------------------- Abort Retry Ignore --------------------------- I am using the image #60480 on a Windows 10 64bits OS -- View this message in context: http://forum.world.st/Iceberg-tp4945776p4945804.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 7, 2017

Re: [Pharo-dev] Iceberg

by Esteban Lorenzano

Yes, there is a bug now in iceberg (I will fix it soon), for now you can go with: IceRepository defaultBackendType: #IceLibgitLocalRepository. Esteban > On 6 May 2017, at 16:41, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi, > > It is amazing to see how fast Pharo progresses and moves closer to release. > Therefore it may happen that after a week of absence there is so much new stuff that I just loose track of changes and sometimes old behaviour does not correspond new reality and "nothing works" :) > Probably it is my case now. I would like to work on a project hosted on github. I tried iceberg:dev-0.4, iceberg:dev-0.5, iceberg-master but didn't succeed.. > > Here is what I get when try to clone repository both from Playground or by using "+" clone button in Iceberg both dev-04 and dev-05 > > <Screen Shot 2017-05-06 at 16.35.49.png> > > If I try to load Iceberg master in the Image I get this: > > <Screen Shot 2017-05-06 at 16.37.28.png> > > I am sure I do something wrong, so I recorded three videos - one for every Iceberg version. > â > Â Iceberg-0.4.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTLTZvejdYTkNfaWM/view?usp=drive…>ââ > Â Iceberg-0.5.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTbDJNZnJMeUJEYk0/view?usp=drive…>ââ > Â Iceberg-master.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVzhGQmJOVzN3akU/view?usp=drive…>â > VM: pharo-mac-i386-201705051953-b8db6de > Image: 60482 > OS: macOS Sierra 10.12.4 > > P.S. Still getting black screen when open an Image until I click... > > Cheers, > Alex

May 7, 2017

Re: [Pharo-dev] First commit

by Stephane Ducasse

Tx evan! We will have a look and this is great to have a new contributor!!! Stef On Tue, May 2, 2017 at 3:23 AM, Evan Donahue <emdonahu(a)gmail.com> wrote: > Thanks. I have resubmitted and it seems to have worked. If anyone wants to > let me know if it looks like I did everything right, I can hopefully move > on > to tackling other things. > > Thanks, > Evan > > > > -- > View this message in context: http://forum.world.st/First- > commit-tp4944984p4945091.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 7, 2017

Re: [Pharo-dev] ./pharo --help returns exit code 1 on ubuntu

by Ben Coman

[CC vm-dev] On Sat, May 6, 2017 at 7:04 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > On Friday 05 May 2017 02:11 PM, Andrei Chis wrote: > >> ... >> ./pharo -help >> unknown option: -help >> Common <option>s: >> --help print this help message, then exit >> >> Then `./pharo -help` returns an exit code of 1 on mac/linux while >> `./pharo --help` returns a exit code of 0 on mac and 1 on linux. >> > > It is --help on Pharo and -help on other compiles (see below). Can anyone > shed light on the legacy compatibility comment in : > > ---- platforms/unix/vm/sqUnixMain.c ---- > 1421 /* legacy compatibility */ /*** XXX to be removed at > some time ***/ > 1422 > Looking just at just the file, it appears this is comment is strongly associated with the code below, but git blame [1] indicates the comment is 7 years old, while the code below is 7 months old. ??? [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/blame/995e7aedc3b5aeb7690… cheers -ben > > 1423 #ifdef PharoVM > 1424 # define VMOPTION(arg) "--"arg > 1425 #else > 1426 # define VMOPTION(arg) "-"arg > 1427 #endif > > It's still not clear why running the vm to print the help of the version >> should exit with an error code. >> > > Agreed. I think --help and --version should return 0. I think the 1 was to > catch incorrect/unknown arguments. > > If I learn the rationale behind the change, I can propose a patch to fix > this. > > Regards .. Subbu > > >

May 7, 2017

Re: [Pharo-dev] Respect Pharo and respect us

by Tudor Girba

+1 Doru > On May 6, 2017, at 12:28 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi guys > > Could we have discussion about ***PHARO*** in the Pharo-dev mailing-list? > Can we get a bit of respect? > Should we create a private dev mailing-list so that we can get our focus? > I start to get bored to have to mute threads. I let you imagine the threads I'm muting. > > In addition, I would really like that you ask yourself when is the last time that you > did something for Pharo if ever. You see doing something for Pharo is as easy as > - removing typo from a book > - adding a comment in a method > - helping a newbie > but often you prefer to talk I know why because this is easy. > > So you do not need to have the perfect X&*^*&^ system to take 10 min of your > great life to HELP (see above) > > Our goal is to build Pharo and we would love other people to help > or at least do not use our bandwidth about other goals. > > So respect Pharo and us. > > Stef > -- www.tudorgirba.com www.feenk.com "We are all great at making mistakes."

May 6, 2017

Iceberg

by Aliaksei Syrel

Hi, It is amazing to see how fast Pharo progresses and moves closer to release. Therefore it may happen that after a week of absence there is so much new stuff that I just loose track of changes and sometimes old behaviour does not correspond new reality and "nothing works" :) Probably it is my case now. I would like to work on a project hosted on github. I tried iceberg:dev-0.4, iceberg:dev-0.5, iceberg-master but didn't succeed.. Here is what I get when try to clone repository both from Playground or by using "+" clone button in Iceberg both dev-04 and dev-05 [image: Inline images 1] If I try to load Iceberg master in the Image I get this: [image: Inline images 2] I am sure I do something wrong, so I recorded three videos - one for every Iceberg version. â Iceberg-0.4.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTLTZvejdYTkNfaWM/view?usp=drive…> ââ Iceberg-0.5.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTbDJNZnJMeUJEYk0/view?usp=drive…> ââ Iceberg-master.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVzhGQmJOVzN3akU/view?usp=drive…> â VM: pharo-mac-i386-201705051953-b8db6de Image: 60482 OS: macOS Sierra 10.12.4 P.S. Still getting black screen when open an Image until I click... Cheers, Alex

May 6, 2017

Re: [Pharo-dev] [Zinc] How do I set the entry limit for ZnMultiValueDictionary?

by Max Leske

> > On 5 May 2017, at 17:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Max, > >> On 5 May 2017, at 16:59, Max Leske <maxleske(a)gmail.com> wrote: >> >> Hi, >> >> I'm performing a legal request that has more than 4000 parameters. This causes the Zinc server to return 400: Bad Request because ZnMultiValueDictionary is limited to 256 entries by default. >> >> The dictionary has the option to remove the limit or to adjust it with a dynamic variable. Unfortunately, I don't see any way to properly configure this without monkey patching Zinc. Ideally, I'd like to remove the limit (which can't be done through the dynamic variable by the way because when the dynamic variable answers nil, the default will be set to 256). >> >> The first thing that comes to mind is to move this setting to ZnConstants, but then I don't see any way to configure ZnConstants either (ZnConstants is referenced directly by its users). Maybe ZnConstants could be changed to hold a concrete constants class (itself by default). >> >> In any case, I think this setting should be configurable and the configuration should be possible through one single entry point, together with options like #codec. >> >> Thoughts? >> >> Cheers, >> Max > > You are the first one to complain about this limit. > > This one and other resource limits exist to protect the client/server against abuse and attacks. I'm aware of that but have not other way to do this right now. We have mod_security with a higher value configured for that. > > I think what is needed is something like ZnServer>>#withMaximumEntitySizeDo: which uses the server option #maximumEntitySize. Would that work for you, you think ? Yes, it would. I've implemented the change, closely following the semantics of #withMaximumEntitySizeDo:. While I was working on that I discovered another problem I had which I also fixed by dispatching to ZnConstants. The problem being, that I set the codec on the server to GRNullCodec, but ZnPercentEncoder would still always use a ZnUTF8Encoder to decode requests. The result was an error when the server tried to write wide strings onto the stream (usually ZnUTF8Encoder: UTF-8 -> WideString, GRPharoUtf8Codec: WideString -> UTF-8). I've attached the patches. A couple of notes: - #defaultMaximumNumberOfDictionaryEntries and #maximumDictionaryEntries: have the same implementation, which is unnecessary in my opinion but I've copied the code from #maximumEntitySize:. - I'm not sure whether storing the option a second time on ZnServer makes sense, but, again, I stuck to the existing implementation - #withMaximumNumberOfDictionaryEntriesDo: also checks the dynamic variable, which is overkill I think, as ZnConstants does the same thing. Again, I stuck to the existing implementation (which means that ZnConstants is actually thread agnostic and references to dynamic variables should probably all be on ZnConstants) Cheers, Max > > Sven > > >

May 6, 2017