On Sun, Mar 10, 2013 at 03:40:01PM +, Mirar @ Pike developers forum wrote:
I for one would appreciate if pike were available in the Debian repo.
I seem to use debian derivates everywhere at the moment...
could the new version go into debian-backports instead?
backports have just been added
On Sat, Jan 26, 2013 at 12:45:01PM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
It reads on the tablespoon measure how many ml it is (15). If you use
an actually spoon, then you get a completely random amount.
it's only completely random if you use
what is not obvious is that i have to change my umask from 0077 to 0022
if i wand to make an installation that is usable by everybody.
the point i am trying to make is that the installation by default should
set the permissions so that pike can be used by everybody, regardless of
the installers
On Fri, Jan 28, 2011 at 03:51:56PM +0100, Marc Dirix wrote:
In the first case, the output of the compilation should IMHO respect the
users umask. And that for all files the same wheter compiled, installed
or dumped.
this is complicated by the practice to use a normal user account to
compile
umask is 0077,
but shouldn't the install script ignore that and set its own umask?
greetings, martin.
On Wed, Jan 26, 2011 at 10:20:02AM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
Why?
because the umask only affects files being created, not copied, which
results in an inconsistent installation. all files, except the dumped .o
files are world readable.
to be more specific to what is happening here, it doesn't make sense for
the dumped .o files to have different permissions than the corresponding
source files.
if the source files are world readable, then the .o files should be
world readable as well. otherwise the users will just see lots of
On Wed, Jan 12, 2011 at 02:30:22PM +, Martin Nilsson (Opera Mini - AFK!) @
Pike (-) developers forum wrote:
string encode_xml(mixed data)
{
string ret = pikedata;
foreach( encode_value(data);; int c )
ret += sprintf(%d/, c);
return ret + /pikedata;
}
but encode_value is pike
hi,
the generated docs at the pike website have not been updated for two
years.
could someone with the right access please give the updating script a kick?
greetings, martin.
can you elaborate on that please?
what else beyond somethig like
typedef function|Callable callable; would be needed? (where Callable
refers to the class example i made earlier)
do you mean it would not be easy to write tests for the implementation
of a callable type?
and what is incomplete
interesting.
that is an object that works like a function because it overrides the ()
operator with `()
but this only works if the argument is not tested with functionp().
or can functionp() be tricked somehow?
greetings, martin.
ah, i didn't notice callablep() yet, (most likely because callable is
not a type).
though i'd still need to use function|object or better something like
class Callable()
{
mixed `()(){}
}
and then use function|Callable in places where i want to accept a callable
argument
greetings, martin.
On Mon, Mar 22, 2010 at 09:35:02AM +, Henrik Grubbstr�m (Lysator) @ Pike
(-) developers forum wrote:
if they were developed outside the main tree, doesn't that mean that they
were not part of the trunk at that time but merged later?
Often they were merged via the cvs module system.
what
that is what i meant with merging. regardless of the method used, they
were combined somehow, now giving the appearance that they were always
part of the repo. but in reality they were not part of the repo until
they were included.
either this point when the modules were added to the main repo,
well, i was not sure if m1 or m2 would be the more logical mergepoint.
if you say it is m1 then we don't need to discuss m2 as it does not make
sense to have two mergepoints here.
greetings, martin.
On Thu, Dec 03, 2009 at 10:55:02PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
If there was backtracking, the second case would return ({abc-})
since %d didn't parse - successfully. Now it's just lost.
on a related topic: is there a way to find out if the format has been
thank you!
the upload to experimental would be useful for the future to make the
process easier, i don't think your upload will be much different from my
own manual assembly if we use the same contents for debian/
also i would hope to see 7.8.316 soon...
greetings, martin.
On Fri, Jul 10, 2009 at 11:00:02PM +, Peter Bortas @ Pike developers forum
wrote:
-if [ X$tmp_node != Xlocalhost.localdomain ]; then
+if [ X$tmp_node != Xlocalhost.localdomain -o X$tmp_node !=
Xlocalhost ]; then
should be:
if [ X$tmp_node !=
On Thu, Jul 09, 2009 at 09:55:02PM +, Peter Bortas @ Pike developers forum
wrote:
What does client.sh --nodename say?
nessie
On Fri, Jul 10, 2009 at 05:20:24AM +0200, Martin Baehr wrote:
On Thu, Jul 09, 2009 at 09:55:02PM +, Peter Bortas @ Pike developers
forum wrote:
What does client.sh --nodename say?
nessie
wait, that's wrong, it comes out with nessie when i run it as root, but
not when i run it as a user
sure, that's not a big deal. and it's nothing a small script couldn't
fix if someone would like to this to be easier.
having the testsuite in the installed pike certainly feels like it being
more accessible for me despite having a checkout of the source tree,
since the tests in the source tree
i get what you are saying, i am just confused why bill seems to
claim that 'new style' modules can not be distributed at all...
i can understand things depending on the state of the system while
building, but as you say that is the same for both styles. (and not
really a problem for packaging
ok, if there is no immideate benefit then it's not worth it to upset the
current release with the changes needed. it would be good enough as a
target for the next stable release.
greetings, martin.
ok, but make install_interactive is the one command that does everything
without needing extrahints to install things in a different location.
iaw you can use make install_interactive without refering to README-CVS,
where as make install needs README-CVS if you want to change the
defaults.
will
are there any further comments on this question?
if not, i'll go aheas and remove vars-include_prefix handling from
--new-style in install.pike
greetings, martin.
but what is the use of --includedir if the value is ignored in
install.pike?
greetings, martin.
is there any reason not to use it?
vars-include_prefix is referenced twice in install.pike. currently that
reference will always be false
if includedir has the wrong value then we could just ignore it and set
include_prefix = $(prefix)/include/pike
which should be overridable just like
On Tue, Jun 02, 2009 at 10:30:02AM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
I'm not sure if there was some specific reason not to use it initally,
or if it even _was_ used initially, and then removed for some specific
reason. However, one
On Tue, Jun 02, 2009 at 11:10:02AM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
--new-style should be unaffected by it, except that install.pike in line
2110 is:
include_prefix=vars-include_prefix||combine_path(prefix,include,pike);
which is rather
On Tue, Jun 02, 2009 at 01:50:03PM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
it still seems odd that in case of --new-style only include_prefix can
be set, but others like lib_prefix are ignored.
Well, the whole idea of --new-style is to collect
On Tue, Jun 02, 2009 at 09:50:05PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
Well, as srb has configured it, the prefix part is necessary to be
able to rebase.
not sure what he set up, but i guess it is something that specifically
allows pushing the rebased branch
well, since cvs is only for stable 7.8, and the svn repo for 7.9 has not been
opened yet, i guess git is the remaining choice.
there is a pikex repo which is open for any pike branch. (how does one
get access to that? my access is not working, even though it should)
greetings, martin.
hmm, you are right, i didn't think sscanf would asign an empty string to
the value and lib_prefix uses the same code,
but it works for lib_prefix because the makefile specifies:
lib_prefix = $(prefix)/lib/pike
so there is always a value.
for include it sets:
include_prefix = @includedir@
see http://en.wikipedia.org/wiki/File:Gotpike.png
what is missing is the actual copyright information on the logo. i could
not find that on the pike site.
a simple page that clarifies that the pike logo is copyright by ida, all
rights reserved (to make clear that it is not gpl like pike itself)
On Mon, Apr 20, 2009 at 04:55:03PM +, Johan Sundstr�m (Achtung Liebe!) @
Pike (-) developers forum wrote:
Odd; I never seemed to have posted this, when the topic was fresh:
well, this kind of topic never goes stale. and the original motivation
(to clarify the license for the wikipedia
On Wed, Apr 01, 2009 at 05:04:36PM +0200, Arjan van Staalduijnen wrote:
arjan, you could just look at pikes Remote module and take some
ideas from pythons multiprocessing module to achive the effect you
are asking for.
Thanks, I will definitely take a look at it.
without having looked
isn't any datastructure in memory in the end a string of bytes?
so what kind of string is meant here?
greetings, martin.
On Thu, Nov 13, 2008 at 11:05:03AM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
It's natural that a single line is easier to visualize and follow than
a tree.
the problem with a rebased tree is that you loose the information of the
exact state of the tree when a commit
ok, the next question is wheter it is worth the effort.
how often will people run into a situation where they need different
names for the same function, also, for this particular case,
why is it even necesary to alias `- to `[], or ``* to `*?
aren't those already linked as fallbacks?
greetings,
i mean functions declared as constants:
constant mywrite = write;
martin wrote that the compiler would not accept 'write' as a constant
expression.
greetings, martin.
On Mon, Nov 10, 2008 at 09:25:03AM +, Johan Sundstr�m (Achtung Liebe!) @
Pike (-) developers forum wrote:
Code being primarily written for people to read and only incidently
for computers to execute, your variable choice could still be right
for you, of course, but you should of course
ah, great, now it all makes sense, thank you!
There'd be fairly little difference on the pike
level, but quite a big one in the internal program structs.
does that big difference imply a lot of work to implement it?
since the compiler can already detect and optimize away any wrapper
function
On Sun, Nov 09, 2008 at 08:00:03PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
and then tail recurse (no need to do anything with the
stack). Iirc it even gets optimized to an alias to the same function
in the identifier table in sufficiently recent pikes (Grubba would
hi,
i am curious about this change:
commit 01b70e932612e6f706a2a2092832475083f4e6c4
Author: Martin Stjernholm [EMAIL PROTECTED]
Date: Tue Nov 4 15:49:22 2008 +
Ported fix from 7.4: Don't use variables to create function aliases. (They
don't cause garbage in 7.6 and later, but
ahh, that explains a lot, thank you!!
greetings, martin.
On Sat, Oct 04, 2008 at 04:00:02PM +, Johan Sundstr�m (Achtung Liebe!) @
Pike (-) developers forum wrote:
(Changing languages once in a while is a good reminder of what you
like in your favourite one. And, occasionally, what it lacks. :-)
indeed it is, unfortunately it takes a lot of work,
On Sun, Oct 05, 2008 at 02:10:02PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
Well, if you want them in pike they have to be objects.
i meant: aren't they objects in java too?
My point is that people might argue that mapping should have all those
variants, just as
On Sat, Oct 04, 2008 at 02:25:03PM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
In short, adding a new pike type for unsigned INT_TYPE would create
lots of work for rather small benefits.
you mean on the C level? since on the pike level that type
On Sat, Oct 04, 2008 at 03:35:01PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
Adding builtin support for unsigned native integers would mean adding
another core runtime type
isn't int(0..4294967295) good enough for that?
Btw, I think we've had this discussion before,
On Sat, Oct 04, 2008 at 03:05:02PM +, Johan Sundstr�m (Achtung Liebe!) @
Pike (-) developers forum wrote:
Some custom applications that handle tons and tons of numbers in that
range and don't want to adapt their logic to use signed integers to
get the range right may well benefit from
well, occasionally someone gets creative and actually expects the
whitespace there to work, and be in for a surprise if that ever
changes...
if that is of any concern it better be changed earlier than later.
also i think it makes for really unreadable code. (but then there are
plenty of other
a rough cut of the diagram is now here:
https://pike.ida.liu.se/development/history.xml
i'll leave beautification to the graphicians
i made this graph using git git diff --shortstat to compare all the
branches. 0.3b and 0.4 are included because there are some changes going
on that would otherwise
yes, i considered doing a similar graph that not only has the releases
but compares changes from month to month (or even week to week, given
one pixel width per week this should make for a nice graph :-)
greetings, martin.
both actually, while 10% of the current code being original means that
there is a lot of new code, it could be that 90% of the original code is
still current, which would means that most of the original code survived
but the whole codebase grew by a magnitude.
do that for each major revision and
true, but if the backport was done with a git cherry-pick they would
have at least the same author and timestamp. (ok, at that point one
might as well explicitly mark the cherry pick...)
greetings, martin.
On Sat, Sep 06, 2008 at 12:40:02PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
Added DMALLOC_USE_HASHBASE mode is
fe982070cac0283b79a3a4a3a54b7865537acab7.
ah, i think i see the problem.
it looks like the backports somehow get indicated as whole merges.
not sure what
On Mon, Sep 01, 2008 at 09:10:02AM +, Marcus Agehall (Roxen IS) @ Pike (-)
developers forum wrote:
The Lysator CVS doesn't like me much at the moment, so I havn't taken
care of it yet. But it's on my todo list.
maybe it's better to put it on pelix or the new server instead?
greetings,
ah, ok, we'll have to live without history then.
in that case it's easy as we just need to start a new branch.
if you put the archive somewhere to download, then i can take care of
that.
is git installed on pelix?
or is shell access available for pike-git.lysator.liu.se?
(i don't want to drag
hi markus,
did you get around to this yet?
if not, yould you please take care of it?
greetings, martin.
for starters, just put the tarball as it is, somewhere to download.
then import it into a repository where we can get write access to it.
greetings, martin.
it is hasty in the sense that in the past weeks we have been focusing on
a 7.8 release and not on a repository change.
i'd like to keep that focus now and do the split right after.
one problem as you accurately describe is that we have been waiting and
nobody has been pushing to switch. now you
i was including the price to actually implement the change in the repo.
dump, edit, reload is way more expensive than fixing a comit and
rebasing.
greetings, martin.
On Tue, Jul 29, 2008 at 05:50:02PM +, Martin Stjernholm, Roxen IS @ Pike
developers forum wrote:
More subcommands to git-stash so that stashes actually get useful:
Earlier the only option was to clear all of them or nothing, which
means that one could only use them to very temporary
git branch -a --contains origin/HEAD
which branches origin/HEAD is contained in.
that means those branches are the same or newer than origin/HEAD from
there you can investigate further.
i usually just look at gitk to see the branch relationship.
greetings, martin.
gitk is tcl/tk
you can get an ascii tree using git log --graph,
everything else would involve graphics of some kind.
greetings, martin.
On Mon, Jul 28, 2008 at 03:25:03PM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
you can get an ascii tree using git log --graph,
I meant of the relationsships between all the branches. Wouldn't that
be git branch rather than git log?
sorry, you need of
such a feature would be really nice indeed, but at the moment it does
not exist. i wonder how hard it would be to add it to gitk.
greetings, martin.
--first-parent seems to only reduce part of the history of merges but
not collapse all linear sequences of commits. (only commits that have
more than one parent or child should be shown.)
greetings, martin.
well, i asked in the #git irc channel, and such afeature does not yet
seem to exist. i think it could be added to gitk though, as it loads
every commit it could check and then hide the irrelevant ones.
greetings, martin.
sorry, you are right,
you would not use the git-merge command for that though (which deals
with changesets only) but do git-checkout comitref -- filename
that's different from merging a changeset.
greetings, martin.
thanks,
remains the question, which one of the two fixes is better.
arguably the added newline produces nicer output, supporting the current
expectation that each readline-write starts at the beginning of the
line, but writing something without a newline in the end is usually
intentional, so
while i have been leaning towards adding the newline, i just came tothe
conclusion that removing the clear is better because if you don't like
the ugly output you can always force a newline (such code could be added
to hilfe for example), but if you don't like the added newline, then
there is no
so, should we go through and remove private everywhere?
replace private with protected?
(btw there are a number of private protected declarations which is
kind of redundant)
or better protected local (since private implies local)?
or just local?
or local optional (since not-public means it's
ah, now i understand. thanks.
that makes sense because unless the variable is declared local it won't
be used anyways. but the same is true for functions, yet, when functions
are overloaded, the original is still accessible though parent::
is there a reason why variables should not behave the
yes, i did indeed miss that.
thank you for pointing it out (i am really just making a lot of
assumptions here in the hope that they will either be corrected or
acknoledged so that i can learn something in the process)
could you explain how that works?
greetings, martin.
sorry, i reread and now i understand what you meant.
i disagree with that.
preventing a string that is not-secured from written somewhere because
the same string is secured elsewhere makes it possible to detect the
existance of a secured string. that is what i see as a danger and like
to avoid.
yes, but that makes the stringor the application that allowed this
particular string to be created broken, but it does not follow that any
application where any one string happens to exist in a secure or
non-secure version is broken.
i expect that this secure feature will be used for much less
just because it is possible to have a string both in a secured and
non-secured version does not negate the advantage of not having secured
strings in swap.
as long as it is not possible to relate a non-secure string to a secure
one this should not be an issue. at least it is no worse than two
the missing messages are not in the list archive at
http://lists.lysator.liu.se/pipermail/pike-devel/2008-June/date.html
either, so the problem must be between lyskom and lysators listserver.
greetings, martin.
On Wed, Jun 18, 2008 at 09:55:03AM +, Peter Bortas @ Pike developers forum
wrote:
What jhs said.
uhm, could you please have a look at the lyskom bridge? half the
messages seem to be dropped. eg on this topic only your two replies came
through, nothing else.
greetings, martin.
i did put it there with the intention to see what difference it might
make. the main observation though is that the same expression produces
different results at different times.
greetings, martin.
strange. the only glitch in the end seemed to be that checkin 1.49 to
lib/modules/Tools.pmod/AutoDoc.pmod/PikeParser.pike did not trigger an
update and didn't appear in code_librarian either until your restart or
until the checkin of 1.5
greetings, martin.
On Mon, Nov 19, 2007 at 11:35:02AM +, Martin Nilsson (Opera Mini - AFK!) @
Pike (-) developers forum wrote:
zero_type(({ UNDEFINED })[0]); // this is 1
array a = ({ UNDEFINED });
zero_type(a[0]);// this is 0
Well, it's not really an interesting case,
On Sat, Nov 17, 2007 at 08:56:47PM +0100, Stephen R. van den Berg wrote:
You can't imagine how much of a relief
it was to notice that importing didn't barf on the Swedish characters
sometimes in the logs and/or files (this was an absolute nightmare when
trying to convert to SVN/SVK).
yes, i
On Sun, Nov 18, 2007 at 12:58:53PM +0100, Martin Baehr wrote:
no, i keep two branches, one for cvs import and one to work in.
i made the exportcommit from the working branch and then tried the
cvsimport on the import branch.
i tried clearing the cvsps cache, but that made no difference.
i
hmm, that's a tricky question.
tags are not commits at all in git.
just line in cvs.
git-cvsimport imports tags just fine.
i assume in svn you create a tag by copying the tree, but then the
cvs2svn importscript seems to create another commit on top of that,
making the tag effectively a branch.
r19906 and r19907
r19906 is release number bumped to 377 by export.pike
which should have the tag v7_2_377
but the tag is recorded in r19907 instead as:
This commit was manufactured by cvs2svn to create tag 'v7_2_377'.
greetings, martin.
subdirectories in the attic? how did that happen? :-)
did you send those changes upstream?
i suppose a diff to the original 1.3.1 should make them easy to pick out
and maybe forward port to 2.0...
greetings, martin.
ok, maybe this is a svn problem.
for git (and i believe for cvs), a tag marks a specific commit and
does not make up a commit in itself.
if a seperate commit is the only way then the solution may be in fixing
git-svn, or just running a script through all the tags. (for each tag,
find the parent
the point would be to allow to use your changes with the cvs2git feature
that is contained in cvs2svn now.
greetings, martin.
both those drawings represent the same kind of tree.
only that one tree has branches of branches, while the other only has
one level of branches:
you could draw the tree like this:
--branch
/
---0.5---0.6---7.0---7.2---7.4---7.6
/ / /
git has support for a number of other revision control systems too.
and i hope some of those other systems will also be able to support
different systems. (most of them seem to support svn)
the trend that i believe this should head into is that all revision
control systems (well at least the
On Fri, Oct 12, 2007 at 02:55:01PM +, Johan Sundstr�m (Achtung Liebe!) @
Pike (-) developers forum wrote:
I may be wrong here, but I think the stuff on pelix is some playground
or similar and that Marcus' imported Pike repository resides here:
https://svn.lysator.liu.se/repos/pike/
thank you. i'd appreciate that.
any extra information can't hurt.
greetings, martin.
On Fri, Oct 12, 2007 at 02:40:01PM +, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum wrote:
What makes 7.0 a branch and nt-tools a non-branch?
my lack of knowledge of the history? :-)
i did notice that delete if the NT directory, and i was wondering where
that stuff
right, any kind of copying and moving in the cvs repo itself is not
detected unless that process hapepned during a branch split, and is
evidenced due to the difference between the branches
so when i detected renames it was because in one branch the file has a
different name than in the other. and
based on the same ,v file
means, the ,v file was copied?
well in that case the complete history would have been copied and the
content would appear double from the first checkin.
greetings, martin.
how is that part of the development model?
they are still branches, wether that information is stored in the
repository or not.
what effect does it have on development if the repository stores them as
branches? especially in svn where branches are just a convention
anyways.
how would following
i have looked at the svn import and i am not sure how to use that.
there is a branches directory which contains the old cvs branches, but
no trunk and, the actual stable branches are not branches.
trying to import that at once will not work, so i'd have to try to
import the branches seperately
i did 'reconstruct' the missing files by importing them seperately and
then merging the result. i
see the pike77added, etc, branches.
greetings, martin.
1 - 100 of 125 matches
Mail list logo
