Re: [Scons-dev] **JUNK** Re: SCons, Mercurial, BitBucket, Git, and GitHub
Bill, sorry that was really a misunderstanding. So far I've been working on the migration Tigris->Roundup. So the "backend" definitely needs to be rewritten for Github. Regards, Dirk Am 31. August 2017 22:47:15 MESZ schrieb Bill Deegan : >Dirk, > >I guess I mis-understood. >I thought there was a version for pushing to github already? > >-Bill > >On Thu, Aug 31, 2017 at 1:20 PM, Dirk Bächle wrote: > >> Hi all, >> >> On 31.08.2017 08:27, Dirk Bächle wrote: >> >> Bill, >> >> [...] >> >> >> >> True. This can also happen after the initial migration. >> Dirk - is it simple to grab the various attachments from tigris? >> >> >> >> I'd say so, yes. Let me dig up the sources for that, which might take >a >> day or two. >> >> >> please find attached a recent version of my migration script >> "Tigris->Roundup". Follow the comments inside to download all current >> issues (including attachments). Then you'll be mostly interested in >> "create_file", it's currently using xmlrpclib to write to a Roundup >tracker >> instance directly. But hooking your own code in for pushing to Github >> shouldn't take that much work. ;) >> >> Best of luck, and have fun! >> >> Dirk >> >> >> >> ___ >> Scons-dev mailing list >> Scons-dev@scons.org >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> >> -- Sent from my Android with K-9 Mail.___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] **JUNK** Re: SCons, Mercurial, BitBucket, Git, and GitHub
Dirk, I guess I mis-understood. I thought there was a version for pushing to github already? -Bill On Thu, Aug 31, 2017 at 1:20 PM, Dirk Bächle wrote: > Hi all, > > On 31.08.2017 08:27, Dirk Bächle wrote: > > Bill, > > [...] > > > > True. This can also happen after the initial migration. > Dirk - is it simple to grab the various attachments from tigris? > > > > I'd say so, yes. Let me dig up the sources for that, which might take a > day or two. > > > please find attached a recent version of my migration script > "Tigris->Roundup". Follow the comments inside to download all current > issues (including attachments). Then you'll be mostly interested in > "create_file", it's currently using xmlrpclib to write to a Roundup tracker > instance directly. But hooking your own code in for pushing to Github > shouldn't take that much work. ;) > > Best of luck, and have fun! > > Dirk > > > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] **JUNK** Re: SCons, Mercurial, BitBucket, Git, and GitHub
Hi all,
On 31.08.2017 08:27, Dirk Bächle wrote:
Bill,
[...]
True. This can also happen after the initial migration.
Dirk - is it simple to grab the various attachments from tigris?
I'd say so, yes. Let me dig up the sources for that, which might take
a day or two.
please find attached a recent version of my migration script
"Tigris->Roundup". Follow the comments inside to download all current
issues (including attachments). Then you'll be mostly interested in
"create_file", it's currently using xmlrpclib to write to a Roundup
tracker instance directly. But hooking your own code in for pushing to
Github shouldn't take that much work. ;)
Best of luck, and have fun!
Dirk
""" Import tracker data from Tigris.org
This script needs the following steps to work:
1. Extract the issues as XML files via the project's xml.cgi:
import_tigris.py files
this will place all the downloaded XML files in the files dir.
An example:
import_tigris.py files scons import
2. Import the data via xmlrpc:
import_tigris.py push
Example:
import_tigris.py push http://admin:admin@localhost:8917/demo/xmlrpc import
And you're done!
"""
import sys
import os
import glob
import lxml
import lxml.etree
from urllib2 import urlopen
import base64
import xmlrpclib
import csv
# -
# natsort: Natural string sorting.
# -
# By Seo Sanghyeon. Some changes by Connelly Barnes.
def try_int(s):
"Convert to integer if possible."
try: return int(s)
except: return s
def natsort_key(s):
"Used internally to get a tuple by which s is sorted."
import re
return map(try_int, re.findall(r'(\d+|\D+)', s))
def natcmp(a, b):
"Natural string comparison, case sensitive."
return cmp(natsort_key(a), natsort_key(b))
def natcasecmp(a, b):
"Natural string comparison, ignores case."
return natcmp(a.lower(), b.lower())
def natsort(seq, cmp=natcmp):
"In-place natural string sort."
seq.sort(cmp)
def natsorted(seq, cmp=natcmp):
"Returns a copy of seq, sorted by natural string sort."
import copy
temp = copy.copy(seq)
natsort(temp, cmp)
return temp
# -
# Download issues from Tigris
# -
def issue_exists(id, url):
""" Return whether the issue page with the given
index (1-based!) exists, or not.
@param id Index (1-based) of the issue to test
@param url Base URL to the project's xml.cgi (no params attached!)
@return `True` if the issue exists, `False` if not
"""
query_url = url + '?include_attachments=false&id=%d' % id
try:
issues_xml = lxml.etree.XML(urlopen(query_url).read())
for issue in issues_xml.xpath('issue'):
error = issue.attrib.get('status_code', None)
if error and error == "404":
return False
else:
return True
except:
pass
return False
def binprobe(left, right, index_exists):
""" Searches the last existing entry in a
"sequence of indices" from left to right (including).
Assumes that "left" starts on an existing entry,
and left <= right, and left >= 0, and right >= 0.
The index "right" may either be the last existing entry,
or points to an entry that doesn't exist.
@param left Start index
@param right End index
@param index_exists Function that checks whether a 1-based index
is in or out of the sequence (exists or not).
@return 1-based index of the last existing entry, in
the given interval
"""
while ((right - left) > 1):
middle = left + (right - left) // 2
if not index_exists(middle):
right = middle - 1
else:
left = middle
# Special handling for when only the two
# last IDs are left...or a single one (left=right).
if index_exists(right):
return right
return left
def get_number_of_issues(url, start_id=1, BSEARCH_STEP_SIZE=1024):
""" Return the 1-based index of the highest available (=existing)
issue for the given base URL, when starting to
probe at start_id.
@param url Base URL to the project's xml.cgi (no params attached!)
@param start_id Index (1-based) from where to probe upwards
@return 1-based index of the last existing issue
"""
# Start at the given index
id = start_id
# Loop in large steps, until id doesn't exist
steps = 0
while issue_exists(id, url):
id += BSEARCH_STEP_SIZE
steps += 1
if steps:
# Start the binary search
left = id - BSEARCH_STEP_SIZE
right = id - 1
return binprobe(left, right,
lambda x: issue_exis
Re: [Scons-dev] Problematic conflicts between C/C++ and D
On Thu, Aug 31, 2017 at 5:11 AM, Russel Winder wrote: > On Wed, 2017-08-30 at 09:28 -0700, Bill Deegan wrote: > > […] > > > > Remember that this is (can be) set by each compiler. > > Indeed, and for tools not in the default set that is the end of the > issue. However for tools in the default set we have the cross-coupling. > > […] > > > Since none of the D compilers are included at the end of the default > > list, > > as it currently stands any change they make to SHOBJSUFFIX would end > > up > > being the default, assuming a d compiler is found. > > I am not sure I follow the first part of this, but the second part is > very true: if I set SHOBJSUFFIX in any f the D tools it is the value > used by cc and c++ tools if the build does not specify a tool list > explicitly. > > > The only issue would come about (currently) if the user set the tool > > list > > to empty and explicitly added the tools with the D tools first. > > Or the user does not set a tool list at all. This is the problem that > was raised by a user. All my D tool use had involved explicitly > setting the tool list in the environment. This leads to an issue with > the gdc tool that I have yet to follow up on. The dmd an ldc tools are > though fine. With there being no tool list set, the default tool set is > used and the problem for the dmd compiler and ldc2 compiler regarding > SHOBJSUFFIX hits. > > > Assuming you change SHOBJSUFFIX in the D tools, it should work fine. > > 'Fraid not. tried that and it means the all the cc and c++ tests fail. > If SHOBJSUFFIX is set in the dmd or ldc tool then it affects the cc and > c++ tools which then fail all their tests. > > > That said, there has been much discussion in the past of revamping > > the tool > > chain & platform logic (see the wiki and mailing list for more > > details). > > Indeed but without more resources, I suspect we are left with what we > have. > > > Due to the current logic dealing with tools individually, it is > > possible to > > construct an environment where the tools are incompatible. > > for example compiler and linker which cannot inter operate. > > > > But for now, if you had a patch where the D tools changed SHOBJSUFFIX > > then > > your immediate and most likely issue should be handled. > > 'fraid not. It may fix the dmd and ldc situation but it leaves all the > cc and c++ related tools broken in the default tool set and so all the > SCons tests relating to them fail. > Can you pastebin the failures? Likely the c/c++ tests have the SHOBJSUFFIX hardcoded which is not correct.. (Unless the tests only load the c/c++ tools or a limited set thereof, which might not be a bad idea anyway as it would speed up the tests..) -Bill ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Problematic conflicts between C/C++ and D
On Wed, 2017-08-30 at 09:28 -0700, Bill Deegan wrote: > […] > > Remember that this is (can be) set by each compiler. Indeed, and for tools not in the default set that is the end of the issue. However for tools in the default set we have the cross-coupling. […] > Since none of the D compilers are included at the end of the default > list, > as it currently stands any change they make to SHOBJSUFFIX would end > up > being the default, assuming a d compiler is found. I am not sure I follow the first part of this, but the second part is very true: if I set SHOBJSUFFIX in any f the D tools it is the value used by cc and c++ tools if the build does not specify a tool list explicitly. > The only issue would come about (currently) if the user set the tool > list > to empty and explicitly added the tools with the D tools first. Or the user does not set a tool list at all. This is the problem that was raised by a user. All my D tool use had involved explicitly setting the tool list in the environment. This leads to an issue with the gdc tool that I have yet to follow up on. The dmd an ldc tools are though fine. With there being no tool list set, the default tool set is used and the problem for the dmd compiler and ldc2 compiler regarding SHOBJSUFFIX hits. > Assuming you change SHOBJSUFFIX in the D tools, it should work fine. 'Fraid not. tried that and it means the all the cc and c++ tests fail. If SHOBJSUFFIX is set in the dmd or ldc tool then it affects the cc and c++ tools which then fail all their tests. > That said, there has been much discussion in the past of revamping > the tool > chain & platform logic (see the wiki and mailing list for more > details). Indeed but without more resources, I suspect we are left with what we have. > Due to the current logic dealing with tools individually, it is > possible to > construct an environment where the tools are incompatible. > for example compiler and linker which cannot inter operate. > > But for now, if you had a patch where the D tools changed SHOBJSUFFIX > then > your immediate and most likely issue should be handled. 'fraid not. It may fix the dmd and ldc situation but it leaves all the cc and c++ related tools broken in the default tool set and so all the SCons tests relating to them fail. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
