.@gmail.com> wrote:
On Sat, May 12, 2018 at 2:31 AM, Lance Dillon <riffraff...@yahoo.com> wrote:
>
> Any suggestions? What are some good options to try? And do I pass them as
> CONFIGUREARGS?
Before all else, I would try again from a clean checkout, i.e.
make distclean
git clean -xf
ckout, i.e.
make distclean
git clean -xf
some good options to try? And do I pass them as
> CONFIGUREARGS?
Before all else, I would try again from a clean checkout, i.e.
make distclean
git clean -xf
On Sat, May 12, 2018 at 2:31 AM, Lance Dillon <riffraff...@yahoo.com> wrote:
>
> Any suggestions? What are some good options to try? And do I pass them as
> CONFIGUREARGS?
Before all else, I would try again from a clean checkout, i.e.
make distclean
git clean -xf
It means that the pike you just build (and which will be used to
generate post-modules from that point on) does not work. Try running
it in gdb?
build pike 8.0 from git, and got an error about Msql:
>
>=== configuring in Msql
>(/home/riffraff/src/pike/8.0/pike/build/linux-4.16.6-302.fc28.x86_64-x86_64/modules/Msql)
>configure: running /bin/bash -norc
>/home/riffraff/src/pike/8.0/pike/src/modules/Msql/configure
>--disab
>So trying to build pike 8.0 from git, and got an error about Msql:
>
>=== configuring in Msql
>(/home/riffraff/src/pike/8.0/pike/build/linux-4.16.6-302.fc28.x86_64-x86_64/modules/Msql)
>configure: running /bin/bash -norc
>/home/riffraff/src/pike/8.0/pike/src/modules/Msql/con
Lance Dillon wrote:
>Hmm, also getting the following error now, building with release PIke-4.0.498:
>/usr/lib64/libc_nonshared.a(atexit.oS): In function `atexit':
>(.text+0x3): undefined reference to `__dso_handle'
Had this too. Tried to get rid of it in more than one way (I'm using Debian
if something is up with that release.
On Thursday, May 10, 2018, 8:56:45 PM EDT, Lance Dillon
<riffraff...@yahoo.com> wrote:
Also, trying to build pike from git, but keep getting:
precompile: /home/riffraff/src/pike-git/src/build/pike -DNOT_INSTALLED
-DPRECOMPILED_SEARCH_MORE -
Also, trying to build pike from git, but keep getting:
precompile: /home/riffraff/src/pike-git/src/build/pike -DNOT_INSTALLED
-DPRECOMPILED_SEARCH_MORE -m/home/riffraff/src/pike-git/src/build/master.pike
/home/riffraff/src/pike-git/bin/make_interpret_functions.pike
/home/riffraff/src/pike
wrote:
So trying to build pike 8.0 from git, and got an error about Msql:
=== configuring in Msql
(/home/riffraff/src/pike/8.0/pike/build/linux-4.16.6-302.fc28.x86_64-x86_64/modules/Msql)
configure: running /bin/bash -norc
/home/riffraff/src/pike/8.0/pike/src/modules/Msql/configure
--disable-
So trying to build pike 8.0 from git, and got an error about Msql:
=== configuring in Msql
(/home/riffraff/src/pike/8.0/pike/build/linux-4.16.6-302.fc28.x86_64-x86_64/modules/Msql)
configure: running /bin/bash -norc
/home/riffraff/src/pike/8.0/pike/src/modules/Msql/configure
--disable-option
The simplest runtime implementation would be non-zero subtype on the
string, to mark that it is binary data and not unicode text.
(Although that might make the stringp operator a bit ambiguous.)
The main benefits are in static typechecking, making sure you don't
send unencoded text to I/O
On Thu, Nov 24, 2016 at 12:40 AM, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se>
wrote:
>>In Python, it's done with a prefix - u"asdf" is a Unicode string, and
>>b"asdf" is a byte string.
>
> Since nominally strings are Unicode (with the
Yes, s will be Unicode. Of course, you need to declare the character
encoding of your source file using a #charset tag (or use a BOM to
indicate UTF encoding).
Well, I'm not sure that's actually abusing it; Stdio.Buffer is a
sort of compromise for getting some of the benefits of a native buffer
type while not getting all of the problems (it does not affect
compatibility as it uses a separate set of APIs, and while that does
lead to inconsistency it's not
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>can also look at Java, which has byte[] as the type for byte strings,
>requiring literals like {'a','s','d','f'}, but I would like to see
In the EngineIO implementation I currently abuse Stdio.Buffer to fulfill this
>It's valid Pike. Pike supports the full ISO/IEC 10646 31-bit range,
>plus an equally large negative range.
Also note that Pike strings doesn't necessarily contain Unicode, even
if they usually do. They _could_ just as well contain RGB pixels or
random memory access data from a 12-bit-word
>Right, and that's something that can't be done in the current
>standard. Hence this entire proposal has to wait until some major
>changes can be done.
Yup. And then those changes should not be a repurposing of an
existing mechanism (element ranges on the string type) but something
more
On Thu, Nov 24, 2016 at 12:20 AM, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se>
wrote:
>>\U12345678 possibly should be an error, as it's not valid Unicode.
>
> It's valid Pike. Pike supports the full ISO/IEC 10646 31-bit range,
> plus an
>By "binary data", I mean eight-bit strings of arbitrary bytes - like
>you'd read from a file or something. Currently, functions like
>Stdio.read_file simply return "string", but they'll effectively be
>returning string(8bit).
No, Stdio.read_file currently returns string(8bit). That simply means
On Wed, Nov 23, 2016 at 11:10 PM, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se>
wrote:
>>I agree, but using string(8bit) to mean "binary data" is something
>>that's 100% backward compatible.
>
> It would not be backwards compatible, since that
Strings with known encoding that can transfer into other strings with
a known encoding easily and readable (and in some cases without any
interaction) would be useful.
For instance,
Stdio.FILE x = ...;
x->set_encoding("utf8");
string s = "räksmörgås";
String t = String.JP2022("\33(BHello,
>I agree, but using string(8bit) to mean "binary data" is something
>that's 100% backward compatible.
It would not be backwards compatible, since that is not what
string(8bit) means today.
>Unicode text would always be referred
>to as string(21bit), even if it happens to contain nothing but
On Wed, Nov 23, 2016 at 10:30 PM, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum <10...@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
Even if it hadn't been, fixing that would have been the correct
course of action. ;-)
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
On Wed, Nov 23, 2016 at 10:00 PM, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum <10...@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
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.
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>>Please review, any comments are welcome.
>This looks wrong:
> if (String.width(msg) > 8)
>msg = string_to_utf8(msg);
>You are always utf8-decoding the string, so you should always
>utf8-encode them.
Well
>Please review, any comments are welcome.
This looks wrong:
if (String.width(msg) > 8)
msg = string_to_utf8(msg);
You are always utf8-decoding the string, so you should always
utf8-encode them.
Most bugs have been eradicated, significant further API changes are unlikely.
I'm using it in a mini-application here now.
I.e. in my application I define two namespaces:
"" : Authentication functions. Supported RPC (Remote Procedure Call) events
are:
- client->server: "gettoken"
The dust has settled (somewhat).
The docs are complete in their first draft.
Still have to figure in the variant declarations for stricter typechecking.
Time to use it in my own project.
--
Stephen.
The dust is starting to settle.
Stephen R. van den Berg wrote:
>I'm adding an event layer on top now (as similar as possible to the one that
>the javascript Socket.IO provides).
The eventlayer turned out to be so thin, that I integrated it instead
of layering it on top. The SocketIO-rooms seem
The implementation (of both EngineIO and SocketIO) is supposedly threadsafe
now. It passes all tests.
I'm adding an event layer on top now (as similar as possible to the one that
the javascript Socket.IO provides).
--
Stephen.
Please review, any comments are welcome.
The docs still need improvement, working on that.
Trying to do this one from the specs results in the same sorry mess as
Engine.IO.
So this again is the result of "specs" combined with a lot of protocol
reverse engineering.
--
Stephen.
Very nice, good work!
I guess the API user could keep track of sid:s and Server objects separately,
if they don’t want a .farm? I'd imagine that the globally shared sid lookup
mapping might be regarded as a security issue in more complex setups, such as
multiple listener ports with different
Please review, any comments are welcome.
The docs still need improvement, working on that.
Currently tackling Socket.IO.
--
Stephen.
Hi Bill.
Can someone grant me the ability to push branches? I've got a few
feature branches I'd like to get feedback on but I can't push them
because they have slashes in them (I assume it's preferred that I
not clutter the branch namespace unnecessarily.)
I believe that you should already
Can someone grant me the ability to push branches? I've got a few feature
branches I'd like to get feedback on but I can't push them because they have
slashes in them (I assume it's preferred that I not clutter the branch
namespace unnecessarily.)
Bill
I've just had to change my ssh keys due to a theft of equipment, and
I need to get my git access back. Can someone update my key(s)? I've
placed the new key(s) in my authorized_keys file on pike.ida.liu.se
Done.
Not really. http://pike.ida.liu.se/development/git/rw-git.xml ought to
describe how to set it up for rebasing.
I could write a few words about it there, if someone fixes me up with
an account on the Roxen server. Either I don't have one, or I've no
idea what the password could be.
they would still be reachable from the reflog though...
Unreachable here means not part of the current branch (see the
documentation). The two settings control how long commits _in the
reflog_ are kept depending on whether they are reachable or not. If
the commits can not be reached from the
On Fri, Dec 24, 2010 at 03:40:02PM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
Actually, the default reflog expire time is 90 days. It's unreachable
commits that have a default 30 days expire time.
Yes, but the old commits _will_ be unreachable once you
Actually, the default reflog expire time is 90 days. It's unreachable
commits that have a default 30 days expire time. Anyway, the blobs
ought to be mostly the same, so I don't think the old history takes
that much more space. Haven't measured it, though.
Note that old stashes also keep
Actually, the default reflog expire time is 90 days. It's unreachable
commits that have a default 30 days expire time.
Yes, but the old commits _will_ be unreachable once you have pulled
all refs and fixed your own local branches.
Anyway, the blobs
ought to be mostly the same, so I don't think
The deed is done.
pike.git has been filtered, and is now open for pushing again.
Of course, you'll need to rebase your work first. As I said before, a
simple git pull should take care of that if you have a branch that
tracks a pike.git branch by rebasing. (Do not use git rebase
@{upstream
Not sure what happened here but it doesn't seem successful:
dark-castle:pike79 $ git config branch.7.9.rebase true
dark-castle:pike79 $ git status
# On branch 7.9
nothing to commit (working directory clean)
dark-castle:pike79 $ git pull
warning: no common commits
remote: Counting
Here's the config (the rebase flag was set just prior to the
procedure):
dark-castle:pike79 $ less .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote origin
Looks ok. Maybe the reflog didn't contain the right things because
the branch wasn't set to rebase the last time you pulled? What do
.git/logs/refs/heads/7.9 and .git/logs/refs/remotes/origin/7.9 look
like?
I've already performed reset --hard now so I don't know if forensics
will be successful.
dark-castle:pike79 $ less .git/logs/refs/heads/7.9
37f43e3a6e557681ba693d5a8a587a84bf649414 Jonas Walldén jon...@roxen.com
1291069055 +0100clone: from git-p...@pike-git.lysator.liu.se:pike.git
37f43e3a6e557681ba693d5a8a587a84bf649414
Oh, one more thing: You'll want to run git fetch -t to update all
tags when you're done with the branches. Otherwise they will still
point to the old SHA:s, and you will not be able to gc those commits.
That should just add one more line to the reflog, so that's quite ok.
Well, if you want to continue digging, you could always do 'git reset
--hard 37f43e3' to get back to where you were, and then try a new 'git
pull' (optionally with '-r'), and see what happens...
I think I'll pass. :-) Anyway, thanks for the hints.
Hm, looking back at your original pull output, I see that some refs
were not updated by fetch. Probably that's why fetch failed, and the
pull bailed out. For example, it says
error: Ref refs/remotes/origin/branches/hubbe is at
06983fde1434ab5470b2fb656c40db32b2e6a971 but expected
OS X is case-insensitive but case-preserving.
Well, sounds like a git bug then.
Indeed, but don't keep your hopes up for a fix. If you tell them
this approach does not work if you want to do X, the usual response
will be don't want to do X then...
There seems to be a core.ignorecase config option that looks relevant.
Maybe worth trying for anyone on OS X who haven't updated yet.
Yep, seems that pulled in the conflicting branches:
dark-castle:pike79 $ git config --global core.ignorecase true
dark-castle:pike79 $ git pull
From pike-git.lysator.liu.se:pike
+ 108b128...5c8e890 branches/hubbe - origin/branches/hubbe (forced update)
+ 4cff4c1...68b88f5 branches
Eh, according to the config file you pasted, you already had
core.ignorecase set to true the first time. What does 'git show-ref
branches/hubbe branches/Hubbe' say?
Indeed, that's odd.
dark-castle:pike79 $ git show-ref branches/hubbe branches/Hubbe
06983fde1434ab5470b2fb656c40db32b2e6a971 refs/remotes/origin/branches/Hubbe
5c8e89060d917cb3b06f831ed7df43e52b125c5c refs/remotes/origin/branches/hubbe
Well, those are the correct refs at least. Maybe the first set has
been moved into .git/packed-refs (which has no case issues,
naturally), and that's why the problem went away?
Anyway, it seems like try once more would be a good recomendation if
pull fails on OS X. :-)
Also note that commits reachable from the reflog will be preserved for
(by default) 30 days. So unless you manually expire your reflogs, the
old commits will not be garbage collected until next year.
Unless somebody protests, the plan is now as follows:
On Sunday (the 12:th), sometime between 10:00 and 18:00 UTC, I will
replace pike.git with a filtered version. The original pike.git will
become available under the name pike-old.git. Complete mappings
between the commit sha:s of the two
So, is it a good idea to add such annotations to the commit messages
of the cherry-picks? Or should I generate notes instead? (Are notes
copied by git fetch?)
I'd prefer use of notes. However, as far as I can see, notes are not
copied by the default fetch rule:
[remote origin]
fetch = +refs/heads/*:refs/remotes/origin/*
AFAIK the reason that tags are copied is that they refer to commits
that are reached from the heads. The easiest way to
Is it of any use before the git folks have decided on a format for it?
With notes it's possible to add the information later on. A
conservative, and in this case adequate, heuristic to use then would
be look for commits with identical author, author date, and commit
message.
Well, if it's just the formatting, one could reformat it manually with
git commit amend (or even have a hook do it automatically).
In this case though, the following caveat comes into play:
| Do not use this option if you are cherry-picking from your
| private branch because the information
In that case there should be corresponding
cherry picks on multiple branches in the repository, and it'd then be
those that should be linked together.
Yes, but the commit filter doesn't know which those other commits
are. I guess it could try to build up some kind of database, so that
if it sees
, and the commit message and author info of commit is replaced
with that of C. I have only done this of commits created after the
migration to git, and the complete list (25 commits) is on the Wiki
page (http://pike-svn.lysator.liu.se/twiki/bin/view/Main/RepoFilter).
A new filtered repository
That's good work! Thank you for your effort.
On the subject of such cherry picks, I noticed not very long ago that
there is a flag -x to git cherry-pick, which is supposed to be used to
record its origin:
-x
When recording the commit, append to the original commit message
a note
This is a heads-up regarding replacing the main Pike git repository
with a filtered copy.
The main reason why we'd want to do that is that there is a syntax
error in the timestamp fields of the commit objects, causing git
fsck to complain about most commits. In order to fix that, I have
run git
It was an experiment in doing backporting the git-way, where the
patch is done to the most recent common ancestor to all the target
branches, and then merged successively into the target banches.
Seems like a failed experiment to me, then. ;-)
If it had been a feature-branch with a descriptive name, then merged
X would have been a reasonable description of the change. Right now
it just looks crazy.
Please always rebase changes consisting of one (or just a few)
commits.
I second that; rebasing and cherry picking is the way to go.
It's a pity that git still hasn't learned Origin headers when cherry
picking, though. But this way of recording the patch relations is
simply too clumsy imo.
At least this method didn't give false merge relations between the
main
It'd be nice if githelper could be extended to block such merges, i.e.
if a commit moves the merge base between any two main (X.Y-style)
branches, it's blocked.
Well, we'd have to add a definition of a main branch to the code
then. Right now it's mostly generic. And if it should work with
Hm, maybe any branch which does not have / in its name could be
considered a main branch?
be done when pushing.
Speaking of branches and permissions, I assume there aren't much rules
in place yet? I'd like to suggest the scheme I adopted for use in
Roxen's internal git, which stems from srb's pikex repo:
o Branches matching user/* can be changed freely by that user,
while other users
But since / is already used in branch names in the new pike repo, a
different separator char is probably better. :, perhaps.
Sounds excellent, but that depends on srb since I'm not going to
maintain it.
If left to srb it could take a while, considering he's been completely
off net for several months afaik (anyone has any idea what he might be
up to nowadays?).
Anyway, it pretty much takes care of itself once set up, but I can
install my script there if I get access to the box. It shouldn't
Looking at the pike-librarian for last friday, I see .gitignore being
fixed for the whitespace problem in 8 branches. So I would have
expected to see 8 commits. But instead I see a 8 commits, and 14
merges. This looks cluttered and bizarre to me. Why weren't the
fixes simply done on one branch
Well, it looks like there is no way in heck for the pre-commit hook to
figure out that the commit is an amend, so we'll have to go with the
kluge.
I also added a hook to check rebases (it can't actually stop the
rebase at the error, but it can at least present them afterwards, so
you know what
Hm, could it be that git diff --cached compares the index to the old
version of the commit, rather than to the parent (of both the old and
new version) of the commit, when making an amend?
In that case, how can the hook know, and compare against the right
version? Of course, the hook doesn't get
output from git ls-tree when check_ident was
called for a file being deleted. I've pushed a simple fix for that,
and I assume the githelper on the server needs to be updated with it
before I can push my 7.9 tree. Or does that happen automatically?
[...], instead I got Removed foreign_ident from unchanged file
foo. I had to reset HEAD^ and commit to get it in when that happened.
Yes, because what the pre-commit hook saw was that you made a spurious
change of .gitattributes, removing the foreign_ident attribute from
foo without actually
Removed foreign_ident from unchanged file foo.
Hm, on second thought, I think this check can be relaxed so that you
are allowed to remove foreign_ident from file foo if foo does not
actually contain any expanded $Id$.
I've now pushed an update to this effect.
Good news everyone!
At long last grubba has returned from his excursions into the land of
commit graph archeology and brings back with him the complete and
unified Pike history in one git repository.
Marcus has been sacrificing copious amounts of defenceless computrons
on the operation
Sidenote: Anyone who has made a checkin the last 3 years automatically
got their ssh keys copied to the git server.
If any oldtimers suddenly decide you want to commit again then use the
same contacts as for creating a new account.
First c0mmit!1!!1 :)
Nah, Comstedt was actually first by opening up 7.9.
So could we please hear the story with the hooks and the idents?
I started to rebase my stuff from the old pikex repo, and I noticed
that the commit hooks don't run on rebase. I guess they still do on
the server though,
Yes, the server hook will check all commits on push if you push to an
existing branch.
I guess you could do an interactive rebase to check them client-side
first?
Even an interactive rebase won't run them, if the commit is done by
the rebase command. So far I haven't found any better way than this:
git rebase -i origin/7.9
*mark every commit with edit*
For every commit:
*note the current commit id*
git reset HEAD^
git commit -C
Speaking of forign idents: The CVS revisions are archived in the
commit messages which gets a bit chatty.
I changed librarian a bit so that the revision messages are removed
from the changelog and inserted after the filenames instead. Those are
the (crev: X.Y) parenthesises on all the old
You don't need to reset; commit --amend runs the hooks. So the For
every commit part can be simplified to
git commit -C HEAD --amend
*check and fix errors*
git rebase --continue
Tried that, but it got through for me:
git commit --amend
*just closed the editor that popped up*
No modified files, so no updates needed.
[detached HEAD f75c04d] Made it more explicit that we avoid yielding in bad
places.
3 files changed, 55 insertions(+), 17 deletions(-)
I closed
Huh? The commit does not modify any files?
What error were you expecting, by the way?
Hmm, no, I'm confused. That message was from the editor. The hooks do
get run, but they let it through.
I was expecting the foreign_ident check to trig there. It misses the
file if I do --amend, but not if I reset and commit:
git commit --amend -C HEAD
[detached HEAD c531787] Avoid yielding
1 - 100 of 316 matches
Mail list logo
