Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

My first CMOD
by Pontus Östlund 23 Nov '16

23 Nov '16

From time to time it so happens that I have to write vanilla CSS (you don't do that 2016 ;) and it gives me such anxiety you wouldn't believe it :D So I went about it and wrote a CMOD wrapper for libsass http://sass-lang.com/libsass <http://sass-lang.com/libsass>. Since I hardly know any C and very very little about the internals of Pike I would very much appreciate if someone would take a look at the module and give me feedback. And also, if you think it fits in the Pike repo, does it fit under Tools or should it be located somewhere else. It really doesn't matter to me personally. Any feedback is welcome. Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69 www.roxen.com <http://www.roxen.com/> | twitter.com/roxen <https://twitter.com/roxen>

3 5

little endian read
by Lance Dillon 23 Nov '16

23 Nov '16

Is there an easy way to read a string from a file and read it in little endian format to convert to int? I have some old file formats that I want to convert, and header information is stored in little endian format. So far I have something like this for a WORD (2-bytes): Stdio.File fp;fp=Stdio.File(filename,"r");string str=fp->read(2);int res=array_sscanf(reverse(str),"%2c")[0]; Trying to find an easy way to make it variable, like 2 or 4 byte ints (there are some DWORDs in the file too). array_sscanf doesn't take parameters for the format, so I can't do "%*c",2 . Thanks..

5 12

Re: Clean-room Engine.IO implementation committed to git 8.0/8.1
by Chris Angelico 23 Nov '16

23 Nov '16

On Wed, Nov 23, 2016 at 10:00 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > If there are no character values >127, then the encoding step is a > no-op, so skipping it buys you nothing except making your code harder > to read. I envision a future time when we can usefully distinguish between string(21bit) and string(8bit), with string(7bit) being trivially transformed into either of the above. As such, calling utf8_to_string or string_to_utf8 would be an actual type conversion (albeit of a subtype, rather than actually requiring any major changes). ChrisA

3 2

Re: Clean-room Engine.IO implementation committed to git 8.0/8.1
by Chris Angelico 23 Nov '16

23 Nov '16

On Wed, Nov 23, 2016 at 10:30 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > I think you are conflagrating range with interpretation. Both a > Latin1 string and an UTF-8 encoded one are 8-bit strings (with a 0-255 > range). What would be useful is a datatype that declares that the > elements are not Unicode characters (as they are in the Latin1 string > case) but some raw binary encoding (as they are in the UTF-8 case), > optionally also specifying which encoding. This has been suggested > before (with "buffer" as a suggestion for the name of the new > datatype), but it has never been implemented due to the difficulty of > introducing such a datatype in a consistent way while still retaining > backward compatibility. > I agree, but using string(8bit) to mean "binary data" is something that's 100% backward compatible. Unicode text would always be referred to as string(21bit), even if it happens to contain nothing but Latin-1 characters. FWIW, I would support an actual division of data types, such that you cannot concatenate one onto the other. But having seen what happened with Python 2 -> Python 3, I would expect this to be a fairly significant backward compatibility break. It'd probably be something for Pike 9.0 or even 10.0. There would be an opportunity to learn from Python here, though, and maybe do things more smoothly. In any case, the first step is to *right now* think about binary data and textual data as different things, and distinguish them and convert them as appropriate. ChrisA

2 1

Clean-room Engine.IO implementation committed to git 8.0/8.1
by Stephen R. van den Berg 23 Nov '16

23 Nov '16

Please review, any comments are welcome. The docs still need improvement, working on that. Currently tackling Socket.IO. -- Stephen.

4 8

Patches from Debian
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 23 Nov '16

23 Nov '16

Although the Autoconf manual says "Avoid running test programs if possible, because this prevents people from configuring your package for cross-compiling."

2 1

Possibly fixed error
by Martin Nilsson (Coppermist) ＠ Pike (-) developers forum 23 Nov '16

23 Nov '16

The following code void main() { write("%O\n", combine_path_nt("/", "/v1/RPC")); string path = "/v1/RPC"; write("%O\n", combine_path_nt("/", path)); } consistently give the following output on Windows Pike 8.0.182 "/v1/RPC" "//v1/v1/RPC" but works as expected on Windows Pike 8.0.358. Can anyone think of a fix that would make this bug go away, or is it just luck in how the compiler puts things together?

3 3

Patches from Debian
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 23 Nov '16

23 Nov '16

The Debian package has accumulated a few patches through the years. Could you perhaps consider applying some of them? https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/bad_size_t_… Fix undefined behaviour/buffer overruns on 64-bit architectures caused by broken redefinition of size_t. Basically the same change as was made to image_jpeg.c in 2008. https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/undefined_h… Protocols.DNS_SD apparently doesn't include the necessary header declaring htons() (arpa/inet.h *or* netinet/in.h depending on platform). The code might compile anyway, but crash later. The rest are actually all HURD related, but should be harmless enough: https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/pthread_stu… Check whether pthread_atfork() is a stub and not just whether it exists. https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/misplaced_M… The conditional #define MAXPATHLEN comes after the first use of it (in src/modules/_Stdio/efuns.c). https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/hurd.patch?… 1. Let realpath() allocate memory itself. 2. Include mach/message.h directly where mach_msg_type_number_t is used. 3. Don't build shared objects any differently than on Linux (-shared, not -Wl,-Bshareable).

3 5

Debug symbols in GL and GTK2
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 23 Nov '16

23 Nov '16

How come src/post_modules/GL/Makefile.in and src/post_modules/GTK2/Makefile.in delete -g*, -W*, and -O* flags from CFLAGS? efb49e63aff070c by Grubba on 2000-09-02 only says "Attempt at fixing a few warnings" and ed4662949516b507 by Per on 1999-11-20 is even terser with "Fixed makefile" (that's from the GTK 1 module). By contrast, GLUT's makefile doesn't do this.

1 0

Pike 8.0.352 release candidate
by Peter Bortas 23 Nov '16

23 Nov '16

Only real change compared to 3.0.350 is that the change entry about fixing websockets is now true. Pike 8.0.352 beta/release candidate: https://pike.lysator.liu.se/pub/pike/beta/8.0.352/Pike-v8.0.352.tar.gz Other builds: https://pike.lysator.liu.se/pub/pike/beta/8.0.352/Pike-v8.0.352-Darwin-15.4… https://pike.lysator.liu.se/pub/pike/beta/8.0.352/Pike-v8.0.352-win32-oldli…

3 2

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