It's that time of year again. Enough fixes have amassed in the stable
Pike to warrant a release. I still have some things on my list that
needs to be fixed before a release, so there will be another week or
two until I make the beta, but start updating the Changelog and take a
look at your
Marcus dump is now available for read-only inspection at
https://svn.lysator.liu.se/repos/pike/ (WebDAV). All 31896 revisions
of it. Marcus has done a monster job merging all repositories together
with an impressive restoration of history.
This is not the final export, especially since the dump
A conversion of the CVS as of this friday (32061 revisions) is now
available on the same URL.
Probably due to stewas change:
o Made IA32 machine code compatible with Darwin IA32 ABI. Enabled
machine code for Darwin.
Is this something you could take a look at?
http://pike.ida.liu.se/pub/pike/beta/7.6.98/Pike-v7.6.98.tar.gz
My TODO list for making a new release is now empty.
http://pike.ida.liu.se/pub/pike/beta/7.6.100/Pike-v7.6.100.tar.gz
I reverted all the rsif changes on 7.6.
The interesting change since 7.6.98 is the fix for the SSL trouble Erik
supplied a test case for recently.
Protest now if you don't think this should be the next stable for some
reason.
Build 102 looks about ready for release, but Windows doesn't want to
work completely as usual. I've uploaded a first try at a Windows
package, but it has some problems:
indices(GL);
DL: Symbol '_GL_add_auto_funcs' not found.
C:/Program Files (x86)/Pike/lib/modules/GL.so:-: Warning: Failed to
I don't like that version of reality.
Why is GL_add_auto_funcs even exported from GL.so? It's only used by
GL, so that could have been resolved link-time instead.
The one in CVS has. The beta hasn't.
I don't think so. It's not a regression. But if I'm unable to get .102
building properly on Windows without changing the source (which seems
likely right now) I'll make another beta.
If by progress you mean that I've had to abandon my WoW addiction this
weekend to try and fix the Mysql module, then yes. If you mean an
actual release then no. We'll see how it goes later tonight.
I'll grab that.
I'll just have to read up on the Debian charter and find a sponsor
again.
We don't use Automake or Libtool which reduces the amount of horror we
are subject to, but replacing autoconf has been discussed more than
once.
The article is very sparse on details though, and the documentation
for cmake does not make it clear how it makes a better autoconf
replacement. Any
What type would write() take in such a scenario? I assume that's given
by the locale (LC_CTYPE, or similar) and not known at coding time.
write takes Pike-strings, where does locale come in?
http://pike.ida.liu.se/pub/pike/beta/7.6.104/Pike-v7.6.104.tar.gz
Me, Grubba, Marcus and Nilsson spent the entire afternoon debugging
win32 until we got it working. So this is what I hope is the final
release candidate.
Ther are more changes than I would have liked since 7.6.102, but they
are
New 102? It should be 104.1.
Ah, ok. Then the feature list is ok.
Good.
Associations doesn't work, so you'll get hilfe when you click on Pike
files.
Ok. That's just a packaging problem.
Aido crashes when loading.
Do you have an old Windows Pike it works with? Rumour has it it might
be a problem in the GL setup that
Irritating.
Thanks. It's still smashing memory in win32 though. Does someone have
a working setup for compiling 7.6 with VC7? I'm tempted to blame the
current troubles on the compiler.
http://pike.ida.liu.se/pub/pike/beta/7.6.108/Pike-v7.6.108.tar.gz
http://pike.ida.liu.se/pub/pike/beta/7.6.108/Pike-v7.6.108.1-win32.exe
Changes since last beta:
o Fixed mktime to work better with out of bounds time fields. [bug 4326]
o Fixed support for big endian 64-bit.
o Fixed -t (tracing) on
Java. Meh.
The only objections has been from jhs. Are we ready to release then?
Unplesant, but nothing I will fix any time soon.
Should I assume Pike 7.7 is so severly broken it's no use trying to
get it to work?
No. You should report stuff like that so grubba can fix it.
And that worked in the last beta? Works well enough on my cc-compiled
pike on bhelliom:
[EMAIL PROTECTED]:/tmp/Pike-v7.6.112/build/sunos-5.11-i86pc% ./pike
-mmaster.pike
Pike v7.6 release 112 running Hilfe v3.5 (Incremental Pike Frontend)
sizeof(indices(GL));
(1) Result: 1013
Good to go then?
There we go. Next up: Fixing the Debian packages. I do not have
network at home this week, so that might take until next week though.
Please upload binaries to pelix.
/ Peter Bortas
Previous text:
15429783 2007-04-25 18:55 /123 lines/ Peter Bortas
Recipients: Pike (-) importmöte för
Make bin_export produces whats needed.
Great, and fixed.
I have new packages for oldstable (sarge) if someone wants to test. If
all goes as planned I'll complete my tests of that and set up
automatic builds of stable and experimental this weekend.
More or less. It's annoying if it doesn't.
The netgods willing I'll release another 7.6 beta this weekend, please
do anything drastic like rewriting the garbage collector the next few
days.
/.../ and most of the time there shouldn't be any error. (Right?)
There could be applications that throw some errors fairly frequently,
so speed can't be ignored. Anyway, with the option to resort to the
err-is_my_error variety, the type comparisons can always be avoided
when performance is very
There are also a whole bunch of debian packages for those so
inclined. Also completely and utterly untested.
http://pike.ida.liu.se/pub/pike/beta/7.6.116/debian/
pike7.6_7.6.116-1.dsc
pike7.6_7.6.116-1_i386.changes
pike7.6_7.6.116.orig.tar.gz
There are also a whole bunch of debian packages for those so
inclined. Also completely and utterly untested.
http://pike.ida.liu.se/pub/pike/beta/7.6.116/debian/
pike7.6_7.6.116-1.dsc
pike7.6_7.6.116-1_i386.changes
pike7.6_7.6.116.orig.tar.gz
Current non-compilation status of 7.7 on Debian Etch:
Compiling modules/files/file.c
/home/peter/hack/Pike/7.7/src/modules/files/file.c: In function
$B!F(Bfile_peek$B!G(B:
/home/peter/hack/Pike/7.7/src/modules/files/file.c:860: error:
$B!F(Bfd$B!G(B undeclared (first use in this
Verified. Thanks.
I'd be delighted if someone who is already a Debian developer took
charge of the packages. Especially if that person works with me to
make sure Debian packages works and can be automatically built without
extra manual work to set it up.
The most likely dependency graph goes like this:
1. Need timestamp for log. ISO sounds like it's standardized and good.
2. Implement log parser.
3. Watch logparser break when format_iso_short is changed.
Other than that there is very little chance of something breaking
internally in programs if
Sounds useful.
This module is *such* a good idea.
tools% grep For the love of all that is holy, write a new Getopt! * | wc -l
6
Getopt is I think the most cut-and- pasty API commonly used in Pike,
and contributes to just hideous code. (It is probably only dwarfed
by Process.create_process, which might be
On Tue, Sep 18, 2007 at 02:00:01PM +, Henrik Grubbstr�m (Lysator) @ Pike
(-) developers forum wrote:
Anyway, the consensus seems to be Why?
is that really the case?
The traffic here and off-list would suggest so.
the 'why' in this discussion seems to be more about the particular
It is probably not in use. Period.
Or more precise, by running make export.
Or more precise, by running make export.
Or more precise, by running make export.
I have no strong feeling about fftw. It's normally not part of my
binary packages at all. Having it a separate package if it pulls a lot
of other stuff probably makes sense.
But why is it pulling x11?
Ouch. Bad dependecy graph.
I propose a scheme where official stable releases are uploaded to
Debian unstable (if needed, selected patches from CVS can be
applied), and packages based on tarballs like
http://pike.ida.liu.se/generated/pikefarm/packages/7.{6,7}/latest [1]
(but unambiguous versions would be preferred) are
It's no directory listing, because the files named in it don't
exist, save for the most recent one. Why is there no public
repository of older snapshot tarballs (in particular, the most recent
well-defined version would be of interest)?
There is no repository of old tar-balls because they aren't
It's on there. The goal is to build as many of Pikes included modules
as possible with pike -x module for 7.8.
Working on it.
We tend to add APIs though. So forward compatibility is supposed to be
guarateed, but not backwards compatibility even between builds.
i also wonder why they have been deleted from the repository itself
instead of using cvs to remove them, which should have placed them into
the attic.
For each new minor we copy the repository and clean things up. We
don't care about being able to check out a compilable 7.6.66 from the
7.7
But it is OK to use it for experimenting if you wish. The SVN server
on Lysator is not very loaded at all.
We should probably stop with the p-ing already. It doesn't make any
sense unless you are familiar with the concept from another
programming language.
I'll try to drum up a beta this weekend.
Maybe I should say it failed. There is a problem with compilation of
Gdbm on Solaris. Configure tries and succeds to link with gcc, but it
then uses /usr/ccs/bin/ld to fail at linking during the actual
compilation. It's not a recent regression. I'm not even sure it's a
regression, but I'd like
The problem is that gcc har built in linkpaths, in this case gcc comes
from the Blastwave archives, and automaticly searches for libs in
/opt/csw. The system ld does not.
I don't think I have it installed on my Windows machines.
Then it should be included.
I would expect it to not add it in the first place. I consider it bad
practise.
Current status is that things work well on the Unix end, but I've let
the Windows port fall into disrepair. You can expect a new build when
this turns green:
http://pike.ida.liu.se/development/pikefarm/result.xml?id=733_341pike=7_6
As some of you may have seen, a new Debian package of 7.6.112 was
uploaded the other day.
Great!
It failed to build on Alpha, however. Apparently a double free or
corruption happened in libjpeg (used by the Image.JPEG module) during
autogeneration og the documentation (which, in the best of
I think I covered all checkins with that URL.
I'm a bit hesitant to endorce that site since the only use I can see
for it is as a source for harvesting developers for recruitment
firms. Since I don't know anyone involved I will have to assume the
bussiness case for the site is:
1. Build community that builds Valuable Persons Database (VPB)
Well, 1 is lower.
Sure you do. å 16362790.
Which is just another sign that it really should have been a config
test.
Me, grubba an Nilsson enumerated the major 7.8 blockers
yesterday. They are as far as we could determine:
[ ] not done
[/] tentatively fixed
[X] fixed
Owner Issue
[ ] grubba Deprecated type should print warnings.
[ ] grubba Implement #pragma to turn off deprecated warnings.
[
Data point: As expected I can't reproduce it on 32bit Linux.
Sure. But non-free what-did-you-say?
Det där blev lite väl minimerat. Se uppdateringen på buggen.
/ Peter Bortas
Previous text:
16493524 2008-05-12 13:56 /30 lines/ Brevbäraren
Recipients: Pike (-) ticket import
Subject: Array gets emptied if modified in function [4537]
'scuse the moonspeak. Was not to supposed to be posted on the list.
Look at the updated version.
Thanks.
7.8 blockers:
Owner Issue
[/] grubba Deprecated type should print warnings.
[ ] grubba Implement #pragma to turn off deprecated warnings.
! [X] zinoKnown crash on Windows.
[ ] mast/zino New Windows build environment.
[ ] per/marcus Performance regression
There are only 19 open bugs against Pike 7.7. Some of them quite
old. Some filed aginast the wrong version. Some should be RESOLVED
INVALID/WONTFIX or CUSTWAIT if we had had one. Some might be real bugs
still existing. If someone feels like doing some good, pick a bug,
test it and leave a comment
Crunch has BTW held up very well and done what it was planned to
for. What it wasn't planned to handle was the IT crash and everyone
leaving Roxen.
I partly agree. -V was made for hassle-less running of stuff you don't
have time to get up to date right now. And I suspect the sprintf stuff
might be major there.
On the other hand we've OK:ed bugfixes without requiring backwards
compatibility before, where it was a clear bugfix. But when it was
We can have this discussion for 7.10. I'm tentatively against it.
For most functions the warning makes sense in strict mode. That's when
you should have a clean, finished function with the cruft removed.
The exceptions become painful though: callbacks and #ifdefs. And
sometimes when you develop in strict mode, because you will have
unused arguments while
No you shouldn't because that would suck. that's why it should be
turned on with a separate #pragma for now. I'm just saying that if
possible to make non-irritating the warning is nice in most cases.
If you handle it yourself you may put it on the blocker list and treat
it as a todo, but it might get removed in June if it's not done by
then.
Only if it's not possible to fix in later builds due to design issues.
void remove(string file, int(0..1) dry_run)
{
werror(Now removing %O\n, file);
// if(!dry_run)
rm(file);
}
Might be somewhat contrived, but leaving unused arguments like this
primarily screws up readability when scanning code. When you develop
it it's perfectly
Since you where the champion of the idea we'll happily resolve this
without action then.
Feel free to discuss inclusion in _7.10_.
Quite.
7.8 blockers:
Owner Issue
[/] Fallback to poll from epoll (from the conference
road map). Implemented, but further testing is
needed, as well as updated documentation.
[ ] Fix gc of Stdio.File (from the conference road
I haven't released anything yet. :) Or did you mean in the snapshots?
On the weekend of 27-29/6 we plan to resolve the remaining issues with
7.8. Some of us will meet in person, some will communicate over KOM.
You are encourage to participate virtually even if your preferred
medium of communication is IRC or other IM-systems.
That would involve remembering my password and how to do it, so no,
not right now. Feel free though. :)
fair enough :-)
i just checked, and i remember.
could you help me with the text though?
like a few more details on what you planto achive? get all solved?
shall i post the remaining blockers?
What jhs said. The blockers on the list should all be solved.
do you have some more pointers on where
Reminder: That would be this weekend.
7.8 blockers:
Owner Issue
[/] Fallback to poll from epoll (from the conference
road map). Implemented, but further testing is
needed, as well as updated documentation.
! [X] Fix gc of Stdio.File. *Working as intended,
There are no requirement about secret strings beeing random. In fact,
I predict that they will be clear text passwords most of the time.
The do-not-swap feature is something I've been bringing up now and
again, but it really isn't the main feature of secret strings. Neither
is hiding secret
That's not secure, it's just
crash-randomly-and-unexpected-in-production because we don't like your
way of using the secure string.
Even if that idea had an merit (which I don't think it does) it has no
use in combination with secure strings. If would in fact make
applications much less secure. Let me exemplify:
Take a webserver, let's call it Roxen. This Roxen loads
user-creatable scripts and modules. The author of the
1 - 100 of 354 matches
Mail list logo
