Release preparations

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 | Next >

Release preparations

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

There is to much churn in 7.7 to get a release out any time soon if it
doesn't stop.  I've been tolerating the noice in Postgres because the
person making the changes is the only person I know that uses
Postgres, but it's time to freeze things now. What's more I'll start
backing out changes that are not discussed, documented and added to
the ChangeLog. Especially when fiddling with core APIs.

Specificly I'm considering backing out this right now:

http://pike.ida.liu.se/development/cvs/diff.xml?module=Pike&file=7.7/lib/modules/Stdio.pmod/module.pmod&from=1.239&to=1.240

Discuss.

Release preparations

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I'm all for freezing and getting a 7.8 out yesterday.

Re: Release preparations

by Martin Bähr :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

it may help to differentiate the type and extent of changes.

* incompatible changes to the api
* additions to the core api
* other additions
* incompatible bug fixes
* other bug fixes
* security fixes
* crash fixes
* ...

then state which of these are allowed as of now, and what needs to be
frozen before a release is possible. (i'd asume anything except security
and crash fixes)

also nice would be to clarify which of these will be allowed for 7.8.x
(after the 7.8 release)

i have a few hilfe tab-completion fixes which would fit in the other bug
fixes category which i'd like to commit before the release, and i hope
to be able to continue to work on hilfe during the 7.8 cycle (i still
have ideas how to improve completion choices and more stuff that is
potentially useful.)

greetings, martin.

Re: Release preparations

by Stephen R. van den Berg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Peter Bortas @ Pike  developers forum wrote:
>backing out changes that are not discussed, documented and added to
>the ChangeLog. Especially when fiddling with core APIs.

>Specificly I'm considering backing out this right now:

>http://pike.ida.liu.se/development/cvs/diff.xml?module=Pike&file=7.7/lib/modules/Stdio.pmod/module.pmod&from=1.239&to=1.240

I am/have been working on a Sql.pgsql module (it's nearly finished now),
which specifically supports the full PostgreSQL native network API
without libpq dependencies (it implements a superset of the existing
Sql.postgres module; it allows (amongst other things) multiple
simultaneous queries to be run on the same database connection).

The module allows for operation in both interactive and Backend/callout
mode, but in order for it to support pushing back the part of the input
stream that was already pulled out of the kernel network layer by the
Backend, it needs to push back an arbitrary blob into the input stream,
to be consumed again.

ungets() doesn't work for that, because it assumes a newline at the end
of the pushed back buffer.

The only other option I have is to derive a special class from the
Stdio.FILE class which does its own buffering (which is what I need to
do if we want to back out the addition).
--
Sincerely,
           Stephen R. van den Berg.

"Your complaint will be ignored in the order in which it was received."

Re: Release preparations

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

That's the information I'd like to see now _on the list_ before each
checkin that changes behaviour. I know you are doing good work with
the Postgres bindings, and I will continue to turn a blind eye to
that.

The putback functionality is good to have, and I don't mind including
it if I was sure "unget()" was the absolute best name for this
function and the documentation was complete¹ and the ChangeLog was
updated and this was generally accepted among other developers. Why
not "unread()" which is less likely to be confused with *gets*()?

¹ @seealso is now incomplete for all the other related functions.

Re: Release preparations

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>it may help to differentiate the type and extent of changes.
>
>* incompatible changes to the api
>* additions to the core api
>* other additions
>* incompatible bug fixes

Discuss on list first. Oh, and I'd better say that refering to a
discussion from more than a week ago is not valid.

>* other bug fixes
>* security fixes
>* crash fixes
>* ...

Be careful, but check what's needed. Obviously behavioural changes
that you think are bugs should be discussed first.

>then state which of these are allowed as of now, and what needs to be
>frozen before a release is possible. (i'd asume anything except security
>and crash fixes)

I don't expect security fixes to be an issue right now, but for all
intents and purposes they are treated in the same category as crash
fixes for a new release.

>also nice would be to clarify which of these will be allowed for 7.8.x
>(after the 7.8 release)

Everything excepts incompatible changes to the API is always fair
games for new point releases, but just with more care than in minor
releases.

>i have a few hilfe tab-completion fixes which would fit in the other bug
>fixes category which i'd like to commit before the release, and i hope
>to be able to continue to work on hilfe during the 7.8 cycle (i still
>have ideas how to improve completion choices and more stuff that is
>potentially useful.)

That is no problem adding to 7.8.x.


7.8 alpha 1 will the cut today, Monday 1500CEST. After that there is a
fair chance 7.8/7.9 will be split off unless grubba and mast tells me
they have a landslide of patches still to come.

Stdio.FILE.unread() (Re: Release preparations)

by Stephen R. van den Berg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Peter Bortas @ Pike  developers forum wrote:
>That's the information I'd like to see now _on the list_ before each
>checkin that changes behaviour. I know you are doing good work with
>the Postgres bindings, and I will continue to turn a blind eye to
>that.

Well, I have fixed and brushed up the existing Postgres driver as much as I
needed for the short term (it is stable in its current form and heavily tested
in a production environment, I don't think I'll be making much changes there
anymore in the future), I'm about to include an alternate driver (pgsql.pike)
which is available as the second method to connect to PostgreSQL databases, and
as it looks now, it is probably going to be the preferred method; over
time the old driver could be deprecated perhaps.

>The putback functionality is good to have, and I don't mind including
>it if I was sure "unget()" was the absolute best name for this
>function and the documentation was complete? and the ChangeLog was
>updated and this was generally accepted among other developers. Why

ChangeLog, didn't know I had to update that, but will do so after we've
decided on what it is going to be called.
The documentation, well, I've had some experience with that now, writing
my own pgsql driver from "scratch", but not nearly enough, so I missed
some of the fine-points there.  I'll see what I can do to brush that up.

>not "unread()" which is less likely to be confused with *gets*()?

You might be right.  The reason why I didn't pick "unread" is because in
English it is usually pronounced as "un-red" (meaning: not read yet), and
we actually want "un-reed" (meaning: reverse the operation of read).
Then again, maybe the alternate meaning of "not read yet" is not so bad
either, because we declare that piece of string to be "unread" as it
were.  I'll change it to "unread", and wait for comments from the rest
here.

>? @seealso is now incomplete for all the other related functions.

I'll check it.
--
Sincerely,
           Stephen R. van den Berg.

Insanity is a gradual process; don't rush it.

pgsql new driver (Re: Release preparations)

by Stephen R. van den Berg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Stephen R. van den Berg wrote:
>Peter Bortas @ Pike  developers forum wrote:
>>That's the information I'd like to see now _on the list_ before each
>>checkin that changes behaviour. I know you are doing good work with
>>the Postgres bindings, and I will continue to turn a blind eye to
>>that.

>Well, I have fixed and brushed up the existing Postgres driver as much as I
>needed for the short term (it is stable in its current form and heavily tested
>in a production environment, I don't think I'll be making much changes there
>anymore in the future), I'm about to include an alternate driver (pgsql.pike)
>which is available as the second method to connect to PostgreSQL databases, and
>as it looks now, it is probably going to be the preferred method; over
>time the old driver could be deprecated perhaps.

I'll make the deadline for 15:00 today, to get the new driver included.
It already has been tested quite reasonably (not in a production
environment yet, though).
--
Sincerely,
           Stephen R. van den Berg.

Insanity is a gradual process; don't rush it.

Stdio (Re: Release preparations)

by Stephen R. van den Berg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

In the process of combing through Stdio.FILE, I found 2 bugs (fixes already
committed), and one small optimisation opportunity.
Any objections against checking this one in as well (it basically moves
some code around, to make getchar() inlinable)?

commit 9c6d0b0b46b53253119390a76883c962be3e2bf2
Author: Stephen R. van den Berg <srb@...>
Date:   Mon Jul 14 12:47:28 2008 +0200

    Make getchar() less filling, and inlinable

diff --git a/lib/modules/Stdio.pmod/module.pmod b/lib/modules/Stdio.pmod/module.pmod
index 8edf78b..fa4aacd 100644
--- a/lib/modules/Stdio.pmod/module.pmod
+++ b/lib/modules/Stdio.pmod/module.pmod
@@ -1897,6 +1897,22 @@ class FILE
     bpos=0;
   }
 
+  private protected final int getchar_get_data()
+  {
+    b = "";
+    bpos=0;
+    return low_get_data();
+  }
+
+  private protected final void getchar_updatelinecache()
+  {
+    if(sizeof(cached_lines)>lp+1 && sizeof(cached_lines[lp]))
+      cached_lines = ({cached_lines[lp][1..]})+({cached_lines[lp+1]});
+    else
+      cached_lines = ({});
+    lp=0;
+  }
+
   //! This function returns one character from the input stream.
   //!
   //! @returns
@@ -1905,16 +1921,13 @@ class FILE
   //! @note
   //!   Returns an @expr{int@} and not a @expr{string@} of length 1.
   //!
-  int getchar()
+  inline int getchar()
   {
-    if(sizeof(b) - bpos <= 0 && !get_data())
+    if(sizeof(b) - bpos <= 0 && !getchar_get_data())
       return -1;
 
-    if(sizeof(cached_lines)>lp+1 && sizeof(cached_lines[lp]))
-      cached_lines = ({cached_lines[lp][1..]})+({cached_lines[lp+1]});
-    else
-      cached_lines = ({});
-    lp=0;
+    if(sizeof(cached_lines))
+      getchar_updatelinecache();
 
     return b[bpos++];
   }
--
Sincerely,
           Stephen R. van den Berg.

Insanity is a gradual process; don't rush it.

Re: pgsql new driver (Re: Release preparations)

by Stephen R. van den Berg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Stephen R. van den Berg wrote:
>Stephen R. van den Berg wrote:
>>Peter Bortas @ Pike  developers forum wrote:
>>Well, I have fixed and brushed up the existing Postgres driver as much as I
>>needed for the short term (it is stable in its current form and heavily tested
>>in a production environment, I don't think I'll be making much changes there
>>anymore in the future), I'm about to include an alternate driver (pgsql.pike)
>>which is available as the second method to connect to PostgreSQL databases, and
>>as it looks now, it is probably going to be the preferred method; over
>>time the old driver could be deprecated perhaps.

The driver has been included, including ChangeLog updates.
In profiling the driver, I notice a 50% slowdown compared to the libpq
based driver.  And while profiling the code, I notice that Pike somehow
is spending *a lot* of time in regular calls to gettimeofday().

Anyone have any idea which part of Pike does that and why?
--
Sincerely,
           Stephen R. van den Berg.

Insanity is a gradual process; don't rush it.

Re: pgsql new driver (Re: Release preparations)

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The backend does that, to process call-outs.

Stdio (Re: Release preparations)

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

No, don't do that.

Stdio.FILE.unread() (Re: Release preparations)

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>>not "unread()" which is less likely to be confused with *gets*()?
>
>You might be right.  The reason why I didn't pick "unread" is because in
>English it is usually pronounced as "un-red" (meaning: not read yet), and
>we actually want "un-reed" (meaning: reverse the operation of read).
>Then again, maybe the alternate meaning of "not read yet" is not so bad
>either, because we declare that piece of string to be "unread" as it
>were.  I'll change it to "unread", and wait for comments from the rest
>here.

I'll push up the cutting of the alpha 'till 1900 CEST to give people
some more time to comment and to let me fix a blocker I'd forgotten
about.

Stdio.FILE.unread() (Re: Release preparations)

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

A new Subversion converted repository can be found as
~marcus/pike_svn.dump.gz on Pelix.  It's missing a few of todays
commits, so I'll start anouther round.  This round took 22 hours.

Stdio (Re: Release preparations)

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Just a note: There's no reason to use both private and protected at
the same time. private is strictly more restrictive, so it implies
protected.

Re: Release preparations

by Martin Bähr :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Mon, Jul 14, 2008 at 12:20:02AM +0000, Peter Bortas @ Pike  developers forum wrote:
> Discuss on list first. Oh, and I'd better say that refering to a
> discussion from more than a week ago is not valid.

what if no discussion is happening?
should that be taken as acceptance for 7.7?

> 7.8 alpha 1 will the cut today, Monday 1500CEST. After that there is a
> fair chance 7.8/7.9 will be split off unless grubba and mast tells me
> they have a landslide of patches still to come.

the split off has not happened yet or did i miss it?
with more questions coming up on what to commit i think having the split
would be nice so that we can commit to 7.9 and then discuss whether
something is good enough for 7.7/7.8 and backport.

doing the split doesn't even necesarily mean that 7.7 needs to move to
7.8, it could stay 7.7 until it's ready for release, but given pikes
tradition that not every x.y.z is a release i guess it would also be fine
if 7.8.0 is an alpha and the real release is 7.8.9 or some other value of z.

greetings, martin.

Re: Release preparations

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>On Mon, Jul 14, 2008 at 12:20:02AM +0000, Peter Bortas @ Pike  developers forum wrote:
>> Discuss on list first. Oh, and I'd better say that refering to a
>> discussion from more than a week ago is not valid.
>
>what if no discussion is happening?
>should that be taken as acceptance for 7.7?

Not really. Ping the discussion.

>> 7.8 alpha 1 will the cut today, Monday 1500CEST. After that there is a
>> fair chance 7.8/7.9 will be split off unless grubba and mast tells me
>> they have a landslide of patches still to come.
>
>the split off has not happened yet or did i miss it?

Nope, we decided to postpone it while grubba cleaned up some
stuff. Then I barely got out the alpha before going on a 1v vacation.

>with more questions coming up on what to commit i think having the split
>would be nice so that we can commit to 7.9 and then discuss whether
>something is good enough for 7.7/7.8 and backport.

No, that doesn't work. We have to be pretty sure there will be no
major backports right after release.

>doing the split doesn't even necesarily mean that 7.7 needs to move to
>7.8, it could stay 7.7 until it's ready for release, but given pikes
>tradition that not every x.y.z is a release i guess it would also be fine
>if 7.8.0 is an alpha and the real release is 7.8.9 or some other value of z.

Sure, the release is unlikely to be called 7.8.0. That is not holding
of a split. I'll be talking to grubba and marcus about it later today.

Re: Release preparations

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>That's the information I'd like to see now _on the list_ before each
>checkin that changes behaviour. I know you are doing good work with
>the Postgres bindings, and I will continue to turn a blind eye to
>that.
>
>The putback functionality is good to have, and I don't mind including
>it if I was sure "unget()" was the absolute best name for this
>function and the documentation was complete¹ and the ChangeLog was
>updated and this was generally accepted among other developers. Why
>not "unread()" which is less likely to be confused with *gets*()?

I considered using Stdio.FILE for monitoring a logfile today, but I
noticed that gets() (and ngets()) destroy their states when they reach
EOF. Would anybody complain if I add an extra (optional) argument to
them to signal that they shouldn't zap the buffers at EOF?

>¹ @seealso is now incomplete for all the other related functions.

Re: Release preparations

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Yes. I want a release this year.

Re: Release preparations

by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I'm still working out kinks and cleaning stuff up too, but I think
that work can continue after the initial release. I've also just now,
in blissful disregard of any release policy, committed a new GSS-API
glue module. The reason is that Roxen requires it to be there.

Remaining things I intend to do are:

o  Contributing my bit to CHANGES.
o  Fixing the http quoting in Protocols.HTTP since noone has objected.

I've also been working on Windows building and got a reasonably
complete package there now (an exception is perhaps Postgres support).
There's one problem here that needs to be sorted out before we can
distribute any windows packages:

In Windows it's necessary to include most of the libs in the package.
Since they commonly are LGPL I reckon that we must also make sure
there's a source package (for the libs) available along with the
binary installer. I haven't done anything yet to create such a
package. It wouldn't be enough to simply have a list of download links
to the respective web sites for the libs, right?
< Prev | 1 - 2 | Next >
LightInTheBox - Buy quality products at wholesale price