Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

Re: Development discussion
by Peter Bortas 15 Aug '14

15 Aug '14

On Thu, Aug 14, 2014 at 4:30 PM, Per Hedbor () @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >> ** remove class equals (too many equals) > > This somewhat obscure point is probably the existence of a whole bunch > of x [op]= op-codes (+=, -=, &=, %= etc) You brought it up, so however you define it is the correct definition. -- Peter Bortas

3 2

Re: Hilfe-crash.
by Chris Angelico 11 Aug '14

11 Aug '14

On Mon, Aug 11, 2014 at 4:20 AM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > After the new code generation I get a consistent crash if I start > hilfe and does arrow up. Not very helpful backtrace though. It seems to depend on having a good-sized .hilfe_history. I was unable to reproduce the crash with no history, or with just a couple of lines. The crash happens as you describe if there are at least 9 lines in history; if there are exactly 8, then pressing up won't crash, but pressing down afterward will. Don't know if that helps at all or not. ChrisA

3 4

Hilfe-crash.
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 11 Aug '14

11 Aug '14

After the new code generation I get a consistent crash if I start hilfe and does arrow up. Not very helpful backtrace though. Pike v8.0 release 3 running Hilfe v3.5 (Incremental Pike Frontend) > Program received signal SIGSEGV, Segmentation fault. 0x00002aaaacd583d8 in ?? () (gdb) bt #0 0x00002aaaacd583d8 in ?? () #1 0x0000000000000027 in ?? () #2 0x00000000008902e0 in ?? () #3 0x00002aaaacd986b1 in ?? () #4 0x00002aaaac12d1b0 in ?? () #5 0x0000000000886338 in ?? () #6 0x00000000008902e0 in ?? () #7 0x000000000095c080 in ?? () #8 0x000000000041e060 in eval_instruction ( pc=0x2aaaacd986b1 "UH\211\345AWAVAUATSH\203\354\bI\211\377M\213w H\215\005\365\377\377\377I\211F(M\213/I\213N8H\213\001H\213I\bI\211E") at /home/nilsson/pike/src/interpret.c:1707 #9 catching_eval_instruction ( pc=0x2aaaacd986b1 "UH\211\345AWAVAUATSH\203\354\bI\211\377M\213w H\215\005\365\377\377\377I\211F(M\213/I\213N8H\213\001H\213I\bI\211E") at /home/nilsson/pike/src/interpret.c:2749 #10 0x000000000041f3b0 in inter_return_opcode_F_CATCH ( addr=0x2aaaac2b4000 "@\323\022\254\252*") at /home/nilsson/pike/src/interpret.c:1291 #11 0x00002aaaacd98699 in ?? () #12 0x0000000000034cf0 in ?? () #13 0x00000000008902e0 in ?? () #14 0x0000000000000000 in ?? ()

2 1

Re: Codepage decoding tables have incorrect data
by Chris Angelico 07 Aug '14

07 Aug '14

On Tue, Aug 5, 2014 at 6:55 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > And I'd be inclined to fix any acctual errors, rather than blindly > following one or the other. :-) > > Just so you know, the MAPPINGS files on unicode.org is not part of > the Unicode standard, so they are no more a standard than RFC 1345 is. Oh! Okay. What is the standard? Where would I find an authoritative set of codepage-to-Unicode character set replacements? All I can confirm is that, with the changes I put through, Pike agrees with Python 3.4, and codepage 437 "looks right", neither of which is anything official. ChrisA

3 4

Re: Codepage decoding tables have incorrect data
by Chris Angelico 07 Aug '14

07 Aug '14

On Fri, Aug 8, 2014 at 1:50 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Ok. Then my approach would be to keep things as they are until > someone comes up with a specific complaint. :-) As I said, the box > drawing stuff is fixed, so feel free to raise a new issue if you find > something else which is a concrete problem. Yeah, I agree. Codepages are a mess anyway; as long as there's some kind of reasonably sane translation done, it's as good as it's going to be. > (As a side note, I think you were justified in assuming thick/double > lines was a font issue. There is no semantical difference, so I > imagine the only reason why Unicode assigns separate codepoints to > them instead of treating them as font variants is for compatibility > with some other encoding that has both...) No idea. To be quite honest, I wasn't even aware of those other box-drawing characters' existence until I came across this... there's so much Unicode that it's impossible to see it all. ChrisA

1 0

Re: Codepage decoding tables have incorrect data
by Chris Angelico 07 Aug '14

07 Aug '14

On Fri, Aug 8, 2014 at 1:30 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > I have pushed fixes for the box drawing characters, and for the > incorrect forms of arabic characters. This includes fixes to IBM 851 > and IBM 868, which were not part of your patch. > > Many of the remaining changes suggested are a bit dubious though. > > For example, in IBM 437 you proposed the following changes: > > 0xe1: GREEK SMALL LETTER BETA -> LATIN SMALL LETTER SHARP S > 0xe6: GREEK SMALL LETTER MU -> MICRO SIGN > 0xed: EMPTY SET -> GREEK SMALL LETTER PHI Like I said, I didn't have an authoritative source (as I didn't know where to find one), and so I used two non-authoritative sources, which happened to agree: the unicode.org files, and Python 3. Up to you what you want to apply; the part that I was most noticing was the box drawing characters, which I thought was actually a font error (as I wasn't seeing the double lines). ChrisA

2 1

Re: Codepage decoding tables have incorrect data
by Chris Angelico 04 Aug '14

04 Aug '14

On Tue, Aug 5, 2014 at 12:20 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>http://www.ietf.org/mail-archive/web/ietf/current/msg47378.html >>http://www.ietf.org/mail-archive/web/ietf/current/msg47387.html >>http://www.ietf.org/mail-archive/web/ietf/current/msg47444.html >>http://www.ietf.org/mail-archive/web/ietf/current/msg47574.html > > These posts appear to be about the _names_ assigned to characters in > RFC 1345, which isn't relevant here. That's true, in the specifics being dealt with at the time, but the general comments that 1345 isn't a standard and has inaccuracies are true of it all. I would still be inclined to follow the unicode.org files rather than RFC 1345; if nothing else, for consistency with other tools. ChrisA

2 1

Missing files in export
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 04 Aug '14

04 Aug '14

I believe src/export_list is missing the following files, which install.pike tries to install: /refdoc/doxfilter.sh /refdoc/doxygen.cfg

1 0

Re: Codepage decoding tables have incorrect data
by Chris Angelico 04 Aug '14

04 Aug '14

On Mon, Aug 4, 2014 at 5:55 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > I haven't checked whether the changes to the codepages that you > suggest make sense yet (the current tables are generated from > RFC1345, so if there is a discrepancy it should be investigated more > closely), but I don't really see any point in adding your script to > the repository... Yeah, that's why I kept that separate. Figured it quite possibly wouldn't be useful :) Poking around on the internet showed up other places where RFC 1345 is discussed due to incompatibilities with current Unicode standards, such as this thread (highlights only): http://www.ietf.org/mail-archive/web/ietf/current/msg47378.html http://www.ietf.org/mail-archive/web/ietf/current/msg47387.html http://www.ietf.org/mail-archive/web/ietf/current/msg47444.html http://www.ietf.org/mail-archive/web/ietf/current/msg47574.html It seems that, in the event of a conflict, the Unicode files should be used rather than RFC 1345, which has been reported as having errors. ChrisA

2 1

Outdated GNU license texts.
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 04 Aug '14

04 Aug '14

I just noticed that lib/modules/Tools.pmod/Legal.pmod/License.pmod/gpl.txt and lib/modules/Tools.pmod/Legal.pmod/License.pmod/lgpl.txt are very old; you should get the current ones from https://www.gnu.org/licenses/gpl-2.0.txt and https://www.gnu.org/licenses/lgpl-2.1.txt. Specifically, the old files in the repo contain an old postal address and gpl.txt refers to LGPL as the "GNU Library General Public License".

3 3

Jump to page:

2026

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