Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Pike 7.8
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 25 Nov '07

25 Nov '07

Crosspost from user mailing list. This is the outcome of the technical side of this years Pike conference. We came to the conclusion that once the following list of items are fixed we are ready to release Pike 7.8. 1. New syntax for getters and setters. The previous syntax where mixed `->foo() {} void `->=foo(mixed v) {} created a virtual symbol foo in the class are now replaced with mixed `foo() {} void `=foo(mixed v) {} I say replaced, but the old syntax remains. Perhaps it should be changed to return syntax error before the release. Also there was a discussion about how modifiers should be handled. Currently the actual getter and setter functions are made private and the "union" of them are used as the visibility for the virtual symbol. This was argued against at the conference and I think the consensus was that the modifiers should apply to the getter and setter functions themselves and a "variable prototype" should be used to change the visibility of the virtual symbol (with the assumtion that typically you would want the virtual symbol public anyway). One (bizarre) example would be protected void foo; public int `foo() { return x; } private void `=foo(int y) { x = y*2; } The new syntax was implemented promptly, but as I said the old one still remains and nothing has been done w.r.t. the modifiers. 2. Adding a method for deprecating methods and symbols. This topic sparked a debate of how new modifiers can be introduced without having to reserve more keywords, with lots of ideas from other languages tossed around. These syntaxes (syntacies? :) were brought up [weak, shared] int f(); @weak @shared int f(); weak shared int f(); where the last one (keyword solution look alike) was most discussed for several reasons. It would not modify the look of the language by introducing extra syntax, but it would also be complicated to implement was the entire prototype has to be parsed backwards. It was also noted that parametrization of modifiers would be desirable, which would complicate the grammer even more. weak shared(Top) int(1..3) f(string s); The conclusion was that further studies needed to be done to solve the new keyword issue. This was not considered a problem for introducting a new deprecation method though, as it was not something anyone was concerned about the looks for. The agreed upon new keyword is __deprecated__, which when added to a symbol should generate a warning when this symbol is used. To supress deprecation warnings a new pragma directive, no_deprecated_warnings, should be added. 3. To pave the way for "real" static (or "shared" as we would call it to avoid confusion) the keyword "static" will be deprecated. While it technically has nothing to do with the __deprecated__ mechanism, its warnings will also be supressed by the new pragma. The (hopefully) not used keyword "nomask", which is an alias for "final" should also be deprecated. It was agreed that a semantic change in protected to make protected symbols accessible in other objects from the same class, was a good ides. 4. The iterator API should be changed to not use LFUNs, but instead more user friendly symbols. No compatibility layer that would enable both old and new iterators at the same time will be implemented due to the complexity (4 combinations of old/new iterator objects being looped over by code using the old/new API). There will of course be a #pike 7.6 mode to use the old API. 5. Support for mutliple backends to be selected between at runtime is something that is needed, since a Pike compiled with epoll support will not work on a system with only poll. 6. In some situations the Stdio.File and file.fd objects reference each other and leak objects/file descriptors. This should be fixed before Pike 7.8. 7. Martin Stjerholm wanted his work with Locale.Charset.EncodeError / DecodeError to be finished before 7.8. It was also suggested that Charset was moved to a top level module. 8. We need to ensure that there are no performance regressions in Pike 7.8. A quick profiling shows that we do have some performance problems which needs to be addressed. Some work begun immediatly by automatically finding between which versions performance dropped. Another action item was to make Pikefarm parse and save the benchmark data performed by xenofarm clients into a database and provide an interface to be able to query and graph the status. 9. The HTTPS regressions since Pike 7.6 should be fixed before Pike 7.8. This was most likely fixed during the conference. 10. The precompiler should move to Tools.Standalone so that cmods works as external modules properly. 11. One item that was discussed during the last day, and thus didn't make the "official" list of 7.8 items was how zero_type/UNDEFINED worked in Pike. After lot of discussions this was agreed upon: class A { int x = 0; int y = UNDEFINED; } A a = A(); zero_type( a->x ); // This should be 0 zero_type( a->y ); // This should be 1 zero_type( a->z ); // This should be 1 has_index( a, "x" ); // This should be 1 has_index( a, "y" ); // This should be 1 has_index( a, "z" ); // This should be 0 (So far this is how Pike currently behaves.) mapping m = ([ "x" : 0, "y" : UNDEFINED, ]); zero_type( m->x ); // This should be 0 zero_type( m->y ); // This should be 1 zero_type( m->z ); // This should be 1 has_index( m, "x" ); // This should be 1 has_index( m, "y" ); // This should be 1 has_index( m, "z" ); // This should be 0 Here the expression m->y will return 0 with zero type 0. This is due to all subtype flags being cleared by the mapping. For symmetry with with the object case this was agreed to to be changed.

10 32

JPEG issues
by Mirar ＠ Pike developers forum 17 Nov '07

17 Nov '07

Anyone had problems like this? | iris% pike | Pike v7.6 release 112 running Hilfe v3.5 (Incremental Pike Frontend) | > string s=Stdio.read_bytes("DSC00354.JPG"); object img=Image.JPEG.decode(s); img->scale(632,474); string t=Image.JPEG.encode(img,(["quality":95])); | (1) Result: Image.Image( 632 x 474 /* 877.6Kb */) | zsh: segmentation fault pike | iris% gdb `which pike` | ... | (gdb) run | [New Thread 47468888552080 (LWP 335)] | Pike v7.6 release 112 running Hilfe v3.5 (Incremental Pike Frontend) | > string s=Stdio.read_bytes("DSC00354.JPG"); object img=Image.JPEG.decode(s); img->scale(632,474); string t=Image.JPEG.encode(img,(["quality":95])); | (1) Result: Image.Image( 632 x 474 /* 877.6Kb */) It's in 7.6.112 to 7.7.39, at least. Image here: http://www.mirar.org/DSC00354.JPG Problem got bad when I upgraded to Ubuntu 7.10, but I'm not sure if that is because of a new jpeglib or a more paranoid glibc. AMD64. Sometimes I get this: | Pike v7.7 release 39 running Hilfe v3.5 (Incremental Pike Frontend)> string s=Stdio.read_bytes("www/DSC00354.JPG"); object img=Image.JPEG.decode(s); img->scale(632,474); string t=Image.JPEG.encode(img,(["quality":95])); | (1) Result: Image.Image( 632 x 474 /* 877.6Kb */) | *** glibc detected *** pike-7.7: double free or corruption (out): 0x0000000000a38490 *** | ======= Backtrace: ========= | /lib/libc.so.6[0x2ac4e5d7eb0a] | /lib/libc.so.6(cfree+0x8c)[0x2ac4e5d826fc] | /usr/lib/libjpeg.so.62[0x2ac4e76b9ffa] | /usr/lib/libjpeg.so.62[0x2ac4e76ba0fb] | /usr/lib/libjpeg.so.62(jpeg_destroy+0x10)[0x2ac4e76b9540] | /usr/local/pike/7.7.39/lib/modules/_Image_JPEG.so[0x2ac4e7483cb8] | /usr/lib/libjpeg.so.62[0x2ac4e76a98ea] | /usr/lib/libjpeg.so.62[0x2ac4e76a6fca] | /usr/lib/libjpeg.so.62[0x2ac4e76a5ef6] | /usr/lib/libjpeg.so.62(jpeg_write_scanlines+0x9f)[0x2ac4e76a2dff] | /usr/local/pike/7.7.39/lib/modules/_Image_JPEG.so[0x2ac4e7485bb9]

1 0

Looking for maintainer of Pike package on FreeBSD.
by Xavier Beaudouin 16 Nov '07

16 Nov '07

Hello there, I am currently the maintainer of Pike Package on FreeBSD. Since I don't have too mutch time and I really focus on others kinds of developments, I am looking for a maintainer for Pike packages on FreeBSD. If there is some FreeBSD users that can handle the support of Pike for FreeBSD, I will be happy to exchange maintainer as soon as possible. Thanks, /Xavier -- Xavier Beaudouin - http://oav.net/

1 0

Protocols.HTTP.Session (https and SSL.pmod)
by Stephen R. van den Berg 15 Nov '07

15 Nov '07

I discovered it "supported" https but didn't start the encryption. Checked in a fix that actually makes it work yesterday, however, after actually doing some encryption exchange with the other side (it seem to work fine so far), I encounter the error below. It seems like the client_rsa member is nowhere to be initialised. Where was this supposed to take place? Indexing the NULL value with "raw_sign". /usr/local/pike/7.7.34/lib/modules/SSL.pmod/Cipher.pmod:243: SSL.Cipher->rsa_sign(SSL.context(),"\1\0\0/\3\1G<v\231""3\r.\20\353>\351\3 12W\337\5\343-\200\202S\370j\214\375\16\260\305\364\362\371""8\351\0\0\b\0 \a\0\5\0\4\0\n" "\1\0\2\0\0F\3\1\23\4\331\335,\213\f\253""0.\207\233\324tn'0\226\215\226X\ 21_/\264pV\35`\6g\367 \360""0:\374\27\214a\31=\243\t\b\35\f\206""7\f\276\3 30N\267\241\343\270\20Q\217\v\26\330\234\264\0\n" "\0\v\0\6{\0\6x\0\3K0\202\3G0\202\2\260\240\3\2\1\2\2\20(L\222!\201\250\30 2\272!2`0r\242G\245""0\r\6\t*"+[1756],ADT.struct()) /usr/local/pike/7.7.34/lib/modules/SSL.pmod/handshake.pike:268: SSL.connection({ })->certificate_verify_packet() /usr/local/pike/7.7.34/lib/modules/SSL.pmod/handshake.pike:1320: SSL.connection({ })->handle_handshake(14,"","\16\0\0\0") /usr/local/pike/7.7.34/lib/modules/SSL.pmod/connection.pike:379: SSL.connection({ })->got_data("") /usr/local/pike/7.7.34/lib/modules/SSL.pmod/sslfile.pike:1469: SSL.sslfile(Fd(11))->ssl_read_callback(0,"\26\3\1\0\4\16\0\0\0") src/backend.cmod:2790: Pike.Backend(1)->`()(0) /usr/local/pike/7.7.34/lib/modules/SSL.pmod/sslfile.pike:1445: SSL.sslfile(Fd(11))->direct_write() /usr/local/pike/7.7.34/lib/modules/SSL.pmod/sslfile.pike:492: SSL.sslfile(Fd(11))->create(Stdio.File("socket", "145.221.55.1:443", 777 / * fd=11 */),SSL.context(),1,1) /usr/local/pike/7.7.34/lib/modules/Protocols.pmod/HTTP.pmod/Query.pike:213: Protocols.HTTP.Session()->SessionQuery()->connect("145.221.55.1",443,1) /usr/local/pike/7.7.34/lib/modules/Protocols.pmod/HTTP.pmod/Query.pike:702: Protocols.HTTP.Session()->SessionQuery()->sync_request("145.221.55.1",443, "GET /internetbankieren/SesamLoginServlet?sessie=zakelijk HTTP/1.1",,,1) /usr/local/pike/7.7.34/lib/modules/Protocols.pmod/HTTP.pmod/Session.pike:156: Request("https://mijn.postbank.nl/internetbankieren/SesamLoginServlet?sess ie=zakelijk" - connected - failed)->do_sync(({"mijn.postbank.nl",443,"GET /internetbankieren/SesamLoginServlet?sessie=zakelijk HTTP/1.1",mapping[3], UNDEFINED})) /usr/local/pike/7.7.34/lib/modules/Protocols.pmod/HTTP.pmod/Session.pike:763: Protocols.HTTP.Session()->do_method_url("GET","https://mijn.postbank.nl/in ternetbankieren/SesamLoginServlet?sessie=zakelijk",UNDEFINED,UNDEFINED,UND EFINED) /usr/local/pike/7.7.34/lib/modules/Protocols.pmod/HTTP.pmod/Session.pike:783: Protocols.HTTP.Session()->get_url("https://mijn.postbank.nl/internetbankie ren/SesamLoginServlet?sessie=zakelijk",UNDEFINED) /usr/local/pike/7.7.34/lib/modules/Protocols.pmod/HTTP.pmod/Session.pike:828: Protocols.HTTP.Session()->get_url_nice("https://mijn.postbank.nl/internetb ankieren/SesamLoginServlet?sessie=zakelijk",UNDEFINED) pbapp:122: /main()->main(1,({"/tmp/pbapp"})) -- Sincerely, srb(a)cuci.nl Stephen R. van den Berg (AKA BuGless). "Good moaning!"

2 4

Stdio.File GC problems
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 15 Nov '07

15 Nov '07

I've heard that there's a problem with Stdio.File objects becoming garbage. Does anyone have a test case for that?

1 0

master()->fc
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 13 Nov '07

13 Nov '07

What's the semantics of the indices in the mapping "fc" in the master? dirnodes insert themselves twice in this mapping, once with ".pmod" on the end and one without, meaning that rev_fc will randomly contain one of these names. However, findmodule() will only accept the version without ".pmod" if the module is not already in fc. This breaks dumping of the Charset module. It seems to me that dirnodes should only insert the name without ".pmod" into fc, is there some special reason why it is inserted twice now?

3 3

codec and Calendar
by H. William Welliver III 16 Oct '07

16 Oct '07

I was thinking it'd be nice to be able to (en|de)code Calendar objects, but sadly, that doesn't appear to be possible: int main() { object x = Calendar.Second(); string y = encode_value(x); werror("%O\n", x); sleep(3); werror("%O\n", decode_value(y)); return 0; } Cannot find Second(Thu 4 Oct 2007 8:40:34 EDT) in ISO. /usr/local/pike/7.7.34/lib/master.pike:4118: master()->find_index (ISO,Second(Thu 4 Oct 2007 8:40:34 EDT),UNDEFINED) /usr/local/pike/7.7.34/lib/master.pike:4311: master()->nameof (@0=Second(Thu 4 Oct 2007 8:40:34 EDT),UNDEFINED) test.pike:4: /main()->main() Now, I'm pretty sure that Calendar.ISO.Second exists, but I know there's a lot of black magic in the Calendar module, so I'm not even sure where to begin. Anyone have any suggestions? Bill

3 2

pike repo imported into git revision control system
by Martin Bähr 13 Oct '07

13 Oct '07

hi, since i recently got the opportunity to start using git for a project, i tried to import the pike repository into git too. the initial result can be seen here: http://www.iaeste.at/~mbaehr/pike.git this tree is an attempt to reconstruct the history of the main branches (0.5, 0.6, 0.7/7.0, 7.2, 7.4, 7.6 and 7.7) it does not (yet) contain the extra branches. when recontructing the branches i noticed a problem with the various branches in cvs missing files. ie, the contents at the tag pre75to767split should be identical for Pike/7.6 and Pike/7.7 but they are not. this happens in all branches, after the split, some files seem to have gotten lost. i am not yet sure what the best way is to fix this. maybe copying the file from the branch that still has it into the branch where it is missing, and then redoing the import based on that, not sure... anyways, take a look, and let me know what you think. greetings, martin.

6 55

Re: objc
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 09 Oct '07

09 Oct '07

>It seems so odd that the libFoundation folks would go down their own >path wrt exception handling. Effectively, they've created a third, >incompatible way of doing things. Grumble. Yeah. Maybe they're aiming for a solution that works with old objc implementations, such as the original frontend by Brad Cox, which do not have @throw (that syntax was invented about 7 years after the main language itself)... >I was wondering if I can install libfoundation next to the Apple >runtime stuff. It's probably too much to expect that would be >possible. Perhaps I need to get a virtual machine set up just for this. It should be possible to install it under a different prefix, if it works under MacOS at all. >> Needs some ISO standardization methinks... > >I wonder if that'd be better or worse... you'd likely end up with 1 >spec that specifies all the various behaviors :O At least that would mean you could find all of them in one place.

1 0

Re: objc
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 08 Oct '07

08 Oct '07

The reason that there is a conflict between libobjc and libFoundation is that libFoundation depends on its own implementation "libobjc.so.lf2" (lf = libFoundation). Why libFoundation can't use the regular libobjc, or why the special lf version don't work as a drop-in replacement, I don't know.

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel