|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
|
|
Release preparationsThere 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 preparationsI'm all for freezing and getting a 7.8 out yesterday.
|
|
|
Re: Release preparationsit 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 preparationsPeter 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 preparationsThat'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>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)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)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)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)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)The backend does that, to process call-outs.
|
|
|
Stdio (Re: Release preparations)No, don't do that.
|
|
|
Stdio.FILE.unread() (Re: Release preparations)>>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)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)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 preparationsOn 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>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>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 preparationsYes. I want a release this year.
|
|
|
Re: Release preparationsI'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 > |
| Free Forum Powered by Nabble | Forum Help |