On 10.08.2014 10:59, Russel Winder wrote:
Can Issue 2964 be marked as Fixed and Closed?
http://scons.tigris.org/issues/show_bug.cgi?id=2964
Done, thanks for noting.
Dirk
___
Scons-dev mailing list
Scons-dev@scons.org
On 10.08.2014 19:24, anatoly techtonik wrote:
Right now the scenario plot is this.
[ ] I feel like SCons is slow.
. it probably because SCons initializes unneeded tools, which take time to
discover their binaries
[ ] I don't want SCons to initialize unneeded tools or search for
Hi Russel,
thanks for the quick reply.
On 09.08.2014 14:02, Russel Winder wrote:
On Fri, 2014-08-08 at 19:07 +0200, Dirk Bächle wrote:
Hi there,
we have another user reporting trouble with SCons 2.3.2, in connection
to the D tool...so it's time for us to act. I checked the sources
On 09.08.2014 15:18, Gary Oberbrunner wrote:
I'll be home in a few days. I have plenty of Windows machines and can
do the required tests. As for not noticing that that change broke
Windows def files, I should have checked that. (There was a new
failure in the Windows buildbot but I didn't
On 09.08.2014 18:01, William Blevins wrote:
As we know Gary and I are Git people who like transient feature
branches
that can be packaged for merge and are not Mercurial experts. The D
changes extended over a very long period in a Mercurial feature fork
with me keeping the
On 09.08.2014 19:33, William Blevins wrote:
Fair; I realize its non-trivial. My complaints with Mercurial aren't
related to one particular event. It's more a personal preference in
tool usability.
If HG suites the needs of the team, I'll just have to muddle through it.
Again, you are
On 09.08.2014 19:35, Russel Winder wrote:
[...]
This happens, because the line
d_compiler = FindTool(d_compilers, env) or d_compilers[0]
adds dmd to the tool list anyway. In the default Tool's generate()
method, the returned list is simply loaded without checking the
existence of tools
On 09.08.2014 19:42, Russel Winder wrote:
On Sat, 2014-08-09 at 15:33 +0200, Dirk Bächle wrote:
[…]
In amongst all the bluster and anger, I think we have iterated to a very
simple solution to both bugs: remove the setting of the symbol in the D
tools since it is problematic and the Fortran
On 09.08.2014 20:05, Russel Winder wrote:
On Sat, 2014-08-09 at 13:33 -0400, William Blevins wrote:
[...]
Our problem is that it seems that maintaining a long running
synchronized clone of a default branch leads Mercurial to having
problems on a final merge. Advice from a Mercurial expert
On 09.08.2014 20:28, Russel Winder wrote:
On Sat, 2014-08-09 at 20:09 +0200, Dirk Bächle wrote:
[…]
I think it is extremely helpful to create this PR right now. The sooner
we can test this in the mainline (and against our Buildbots), and the
sooner users can pull a fixed version straight from
Hi there,
we have another user reporting trouble with SCons 2.3.2, in connection
to the D tool...so it's time for us to act. I checked the sources, and
the user's analysis appears to be partly correct: even when no D tool is
present in the current system, the dmd tool gets loaded (meaning
On 08.08.2014 03:37, Bill Deegan wrote:
Dirk,
Merged.
Let's see how that works!
Looks good already...one failing test left, for which I opened PR #163.
Regards,
Dirk
___
Scons-dev mailing list
Scons-dev@scons.org
Hi Mark,
On 08.08.2014 17:05, Mark A. Flacy wrote:
Greetings,
While answering a question on the users list, I referenced
http://www.scons.org/doc/production/HTML/scons-user.html#idp24303632
I went back and read it more closely and noticed that the output in the final
examples don't match the
On 07.08.2014 01:39, Dirk Bächle wrote:
Hi guys,
[...]
I removed the /tmp/par-* folders, and biber seems to work again
(versions of biber and biblatex match locally).
In the next days, I'll let another pull request follow to get my
Buildslaves green again
Okay, I created pull request
Rob,
On 08.08.2014 00:04, Managan, Rob wrote:
Dirk,
I just realized that my desktop got updated to TeXLive 2013 recently
and I now have biblatex 2.8 and biber 1.8 available (previously I was
using versions 2.2 and 1.2 respectively). With those versions I still
get the .bcf file generated.
Hi guys,
On 30.07.2014 16:11, Managan, Rob wrote:
Hi Bill,
For test/TEX/biber_biblatex.py we get:
biber returned an error, check the blg file
I suspect that the installed version of biber is mismstched with the
version of biblatex and errors out. I guess I need to find a way to
figure out
Hi Mark,
On 02.08.2014 01:49, Mark A. Flacy wrote:
On Friday, August 01, 2014 05:22:39 PM William Blevins wrote:
SCons Java doesn't need to be that fancy, but I think the root problems can
be solved. The SCons java tool simply doesn't get the love that some of the
other tools get.
One common
Hi,
On 30.07.2014 19:05, William Deegan wrote:
Dirk,
What OS is your fedora7 buildbot slave running. Is it still Fedora 7?
it's running Fedora17, as the info page correctly states:
http://buildbot.scons.org/buildslaves/fedora-17
. It's just the slave's name that somehow (*cough*) got
On 30.07.2014 19:59, Bill Deegan wrote:
Dirk,
I can change the name to 17 and restart if you can update the slave on
your side?
-Bill
Okay, let's do that. Do I have to change some config first, or do I
restart the slave right away?
Dirk
___
Hi Russel,
On 30.07.2014 22:18, Russel Winder wrote:
On Wed, 2014-07-30 at 19:57 +0200, Dirk Bächle wrote:
it's running Fedora17, as the info page correctly states:
Isn't Fedora 17 just a teensy weensy bit out of date? (given Fedora 20
is current and 21 pending?)
yes, but my understanding
Of *William Blevins
*Sent:* Monday, July 28, 2014 7:34 PM
*To:* SCons developer list
*Subject:* Re: [Scons-dev] Pleased to announce we've added Dirk
Bächle as a comitter to the core scons repo
Yeah Dirk!
Thanks guys! :)
Dirk
Hi Jörg,
On 26.07.2014 22:16, Jörg Frings-Fürst wrote:
Hi,
my name is Jörg Frings-Fürst and I live in a small village near by
Trier, Germany.
and welcome to the scons-dev mailing list. Good to have you on board.
I'm the new debian maintainer for your program scons and scons-doc.
Now I'm
On 20.07.2014 17:13, anatoly techtonik wrote:
On Sun, Jul 20, 2014 at 12:48 PM, Dirk Bächle tshor...@gmx.de wrote:
[...]
I do, because I'm subscribed to the Tigris Issue mailing list. Every other
subscriber should see your comments too. Additionally, each issue has a CC
list, where
Hi there,
a bug report about the allegedly broken Split() method, my comments and
the submitted patch to reach backward compatibility for Python 2.6 have
caused some confusion.
So, I'd like to ask again: What is our current Python floor version for
development (default branch)? My
Hi there,
On 06.07.2014 14:25, Andrew Featherstone wrote:
Hi All,
I was wondering what the current state of issue tracking is for the
SCons project. There was some talk a little while back about moving
away from Tigris to a different issue tracker, has that happened? I
thought I'd have a
On 12.07.2014 23:43, William Blevins wrote:
Back to 2395:
My python expertise isn't 5 star, and I'm confused on how to propagate
a symlinks argument down.
I'm a little confused, too...
What I imagine my SConscript should do: env.InstallAs( a, b,
symlinks=False )
because that's not what
On 12.07.2014 16:32, William Blevins wrote:
For 1771, my protoc builder changes aren't important.
This is not so much about importance, but traceability and being able to
reproduce your findings later. Take a look at issue #1438 in the bug
tracker. It's now suggested by Andrew to get closed,
On 10.07.2014 02:37, William Blevins wrote:
*More duplicates (just looking at java issues atm):*
2432 -- Duplicates 1772
I'm not sure about this one. Gary, can you have a short look please?
1849 -- Duplicates 1594
2547 -- Duplicates 1594
2548 -- Duplicates 1594
2046 -- Duplicates 1594
On 12.07.2014 17:26, William Blevins wrote:
Is there also a guide for running the tests? Seems there are 3 sets.
Yes, there is...check QMTest/test-framework.rst, also available at
http://scons.org/wiki/DeveloperGuide/TestingMethodology .
___
William,
On 11.07.2014 05:03, William Blevins wrote:
I'm not sure how to progress with this? We discussed cleaning up the
open issues in another thread, but I don't know enough about how
issues are managed to be making changes without direction and/or get
permission.
I'll go through the
Andrew,
On 07.07.2014 19:47, Andrew Featherstone wrote:
I'm likewise, William, but I think that all users can add some value
by wandering through the open issue list and seeing if we can improve
things by clearing issues that are known to be resolved, testing old
issues against current
On 07.07.2014 22:01, anatoly techtonik wrote:
On Sun, Jul 6, 2014 at 3:25 PM, Andrew Featherstone
andrew.featherst...@cantab.net wrote:
Hi All,
I was wondering what the current state of issue tracking is for the SCons
project. There was some talk a little while back about moving away from
Andrew,
On 06.07.2014 22:25, Andrew Featherstone wrote:
Hi Dirk,
Ok it's good to know where to be looking. For me the number of open
issues gives a (false) negative impression that the project's
development is stale. For me, P1 bugs are triaged as is an issue
which causes detrimental
Hi Anatoly,
On 05.07.2014 09:20, anatoly techtonik wrote:
Hi William,
Because nobody from developers objected, I already sent request to
botbot.me, even though I didn't tick the [ ] op mark. Another reason
for me to pushing on op is to increase the bus factor on the channel.
I understand your
On 05.07.2014 10:30, Dirk Bächle wrote:
Hi Anatoly,
On 05.07.2014 09:20, anatoly techtonik wrote:
Hi William,
Because nobody from developers objected, I already sent request to
botbot.me, even though I didn't tick the [ ] op mark. Another reason
for me to pushing on op is to increase the bus
Hi Bill,
On 10.06.2014 20:03, William Deegan wrote:
Dirk,
I’d have to disagree.
That's okay. ;)
I don’t think new toolchain logic is imminent.
Having a clean build on buildbot across all the available platforms is
a simple way to verify thinks are “OK”.
Right, and not all dots are on
On 25.05.2014 19:14, Gary Oberbrunner wrote:
I'd like to kick off a round of discussion about toolchains, so can
make some progress toward a design. I have some preliminary thoughts.
Please comment. Apologies for the HTML mail, let me know if this
isn't readable for you.
I just stumbled
William,
thanks for your quick reply.
On 31.05.2014 01:39, William Blevins wrote:
Dirk,
Team,
I have a couple points I'd like to discuss, but for the sake of
organization, I intend to split them into separate emails.
Java Part #2
There has been some discussion on making
Hi William,
please find a few comments below.
On 30.05.2014 02:42, William Blevins wrote:
Team,
I have a couple points I'd like to discuss, but for the sake of
organization, I intend to split them into separate emails.
Java Part #2
There has been some discussion on making Scons more
Hi Gary,
here are my comments:
On 25.05.2014 19:14, Gary Oberbrunner wrote:
I'd like to kick off a round of discussion about toolchains, so can
make some progress toward a design. I have some preliminary thoughts.
Please comment. Apologies for the HTML mail, let me know if this
isn't
On 24.05.2014 20:34, Gary Oberbrunner wrote:
I've just reviewed and closed many of the issues in your first set.
More to do of course but it's a start.
Cool, that's a whole bunch off issues fixed/resolved. Nice, and thanks
for having a look!
Dirk
On 21.05.2014 00:53, Gary Oberbrunner wrote:
That's an insidious combination of problems there. I don't think much
is expected to work if only g++ is defined and not gcc, but it would
be nice if it didn't fail this badly. Of course the mythical toolchain
revamp will prevent this kind of
Hi there,
I'd like to get a second opinion (and third, and...) on the following
problem:
I'm currently debugging issue #1742 and found out why the TryLink()
sometimes returns successful, although this shouldn't happen. In the
given example
env = Environment(tools = ['g++', 'gnulink'])
On 20.05.2014 23:58, Dirk Bächle wrote:
[...]
I'm currently debugging issue #1742 and found out why the TryLink()
sometimes returns successful, although this shouldn't happen. In
Sorry, just noticed this right now (better late than never ;) )...it
should be either
...sometimes returns
Hi there,
I've done some cleanup work in our Tigris bug tracker (marking
duplicates and such) and noticed a few issues that might get closed
right away. When I list items in the following, complete with ID and
assignee, this is not meant as an order to take immediate action. Please
don't
Hi Michael,
On 16.05.2014 18:42, Michael Haubenwallner wrote:
Hi,
based on the pull requests #138 #139 #140, fixing various issues,
now I've been able to get the aix-soname thingy into SCons.
However, as a SCons newbie, I'm unsure whether the way I've implemented
this into SCons is based on
Hi Michael,
On 13.05.2014 13:50, Michael Haubenwallner wrote:
Hi,
I'm wondering if the Issue Tracker still is used by the SCons developers,
it's still the only official tracker that we have...and use.
Dirk
___
Scons-dev mailing list
Hi all,
On 05.05.2014 02:45, Dirk Bächle wrote:
On 05.05.2014 02:01, William Deegan wrote:
Do we know the specs of the server pair is providing us with?
roundup suggests mysql or postgressql for database.
Need be we can put roundup on the same server as buildbot.
I’ve installed and customized
Hi Rob,
On 06.05.2014 17:37, Managan, Rob wrote:
I probably have not read any of the workflow docs lately but I don't
remember having to update the MANIFEST.in file when a new file is
added. Of course, I may never have added a file before. Is it the
responsibility of a developer that adds a
On 06.05.2014 20:51, anatoly techtonik wrote:
PTAL. https://bitbucket.org/scons/scons/pull-request/135/
What does PTAL mean? ;)
Sorry, but I couldn't resist.
Dirk
___
Scons-dev mailing list
Scons-dev@scons.org
On 05.05.2014 18:21, Russel Winder wrote:
I think I have forgotten how to use the runtest.py script for executing
tests of tools that are not in the SCons heirarchy and the help isn't
helping.
| python /home/users/russel/Repositories/Mercurial/Masters/SCons/runtest.py
test
1/1 (100.00%)
Hi there,
I'm currently wading through our issue list at tigris.org, trying to
clean things up a little (closing resolved bugs and such...). Sorry, if
this creates some noise on the corresponding mailing list...
I found issue #2739, which is in state STARTED but assigned to
On 04.05.2014 14:29, Gary Oberbrunner wrote:
On Sun, May 4, 2014 at 7:38 AM, Dirk Bächle tshor...@gmx.de wrote:
[...]
This is a great start. Thanks for doing it! My preference would be a
hosted bugtracker though, just because it's one less thing to manage
(keep patched, ensure uptime etc
On 04.05.2014 15:49, Gary Oberbrunner wrote:
[...]
Maybe it would be worth the try to setup a demo instance of roundup. We
could run it in some kind of read-only mode, updating its data from the
Tigris tracker time to time.
This should be pretty easy I think, presuming its dependencies are not
On 04.05.2014 20:31, Russel Winder wrote:
On Sun, 2014-05-04 at 09:49 -0400, Gary Oberbrunner wrote:
[…]
Yeah, seriously. Along with that I really hate the Tigris bug-tracker
interface. It is so needlessly complicated and hard to work with.
It's not even easy to _find_ it from the main tigris
On 05.05.2014 02:01, William Deegan wrote:
Do we know the specs of the server pair is providing us with?
roundup suggests mysql or postgressql for database.
Need be we can put roundup on the same server as buildbot.
I’ve installed and customized bugzilla for many many clients, so if you like I
On 03.05.2014 17:54, Russel Winder wrote:
On Sat, 2014-05-03 at 14:03 +0200, Dirk Bächle wrote:
just saw that PyConUK ( http://pyconuk.org/ ) has started their call for
proposals (talks/sprints/whatever), that get accepted by 19th August. I
guess this mainly goes out to Russel
On 01.05.2014 14:46, Gary Oberbrunner wrote:
On Thu, May 1, 2014 at 7:05 AM, Dirk Bächle tshor...@gmx.de
mailto:tshor...@gmx.de wrote:
...
FYI, I'm currently working on this (
https://openhatch.org/bugs/issue972 ) . The basic implementation
of the Tigris bugimporter
Hi,
after the big Wiki attack in 2013 and the restoring of old contents,
the SCons pages still show the red banner with a warning message at the
top. Maybe it's time to switch this off, to make the Wiki appear a
little friendlier?
Along the same lines, we might consider removing the
Hi Bill,
On 30.04.2014 00:33, Bill Deegan wrote:
All,
If someone can point me to a pylint command line which should work for
scons repo, I can add it to buildbot.
the fix to astroid seems to be working fine. I installed the latest
version of pylint:
logilab_common 0.61.0
astroid
Hi William,
On 01.05.2014 01:01, William Roberts wrote:
I typically set up my builds with a hierachical layout and a variant
directory and do some other things to make it all work together.
Normally I program in C, and this all works.
Recently, I tried using java and broke. I have a very
On 28.04.2014 07:48, Russel Winder wrote:
Since the floor version of SCons is now Python 2.7, we should dispense
with the horror that is 1970s C-style octal constants and use the 0o
form (*). This applies to the default/default branch just as much to the
default/python3-port branch (where it is
On 27.04.2014 17:53, Gary Oberbrunner wrote:
[...]
Funny you should mention that. I'm just adding SCons to openhatch
(http://openhatch.org/projects/SCons) per your email last week and my
conversation with their leader. I added our tigris tracker, or at
least tried to... we'll see if it
On 23.04.2014 01:42, Bill Deegan wrote:
Dirk,
So if I understand correctly, the stubprocess patch passes all the
regression tests and is signficantly faster than the current
implementation?
That's correct, but I'm not sure whether things like the redirection of
stdout/stderr works in all
Hi guys,
I just found this talk by Christine Spang, given at the PyCon 2014 in
Montréal:
http://pyvideo.org/video/2640/subprocess-to-ffi-memory-performance-and-why-y
It's really worthwhile to watch, I think. However, I don't think CFFI
can solve our basic problem...it looks as if there is
Hi Ram,
On 11.04.2014 21:06, Ram Bhamidipaty wrote:
How do I track build variable changes in a tool ?
In my case I have a tool that I invoke like this:
env.MyTool(file.o [file.c], V1=1, V2=2, ...)
The tool is a bit complicated - I use Builder() objects to construct a
file that contains the
On 09.04.2014 19:24, Bill Deegan wrote:
Dirk,
That's pretty impressive!
Does it pass the full regression suite?
No, it doesn't work:
501/1110 (45.14%) /usr/bin/python -tt test/LEX/live.py
/home/dirk/workspace/scons_dirkbaechle/src/script/scons.py returned 2
STDOUT
On 09.04.2014 23:56, William Deegan wrote:
Dirk,
Is this available in your bitbucket repo?
(URL?)
No, I just used the subprocess.py from Eugene's mail and put it in my
local copy of the SCons source tree (plus the import in posix.py).
I didn't bother to add it to any repo yet...
Dirk
Hi Jason,
On 05.04.2014 00:17, Kenny, Jason L wrote:
I think yes, in that it does what should be done by the system under
posix_spawn.. ie call vfork and execve.
Here is the last version of the monkey patch I have from the people
working on it. It has a fallback to the classic fork exec if
Hi Eugene,
thanks a lot for your quick answer and very helpful advice.
On 06.04.2014 15:21, Leskinen, Eugene wrote:
I have just place the stubprocess.py to
/opt/python27/lib/scons-2.1.0/SCons/Platform/ directory and added
'import stubprocess' statement to SCons.Platfrom.posix module just
On 02.04.2014 23:38, Gary Oberbrunner wrote:
On Wed, Apr 2, 2014 at 4:51 PM, Dirk Bächle tshor...@gmx.de
mailto:tshor...@gmx.de wrote:
This idea may be feasible, but I'd rather try to get the actual
shell spawning to be as fast as possible. We have some valid
approaches
Hi there,
On 01.04.2014 18:13, Gary Oberbrunner wrote:
I've found posix spawn can be much faster than fork/exec with large
memory processes, so I'd be in favor of this. Not every system has it
though so there would have to be a fallback to fork/exec.
--
Gary Oberbrunner
(sent from my
Hi there,
On 19.03.2014 15:08, Gary Oberbrunner wrote:
This is worth reading, IMHO. From Martin Geisler. You can see more
in the pull request (which has been withdrawn, so you won't see it by
browsing open PRs on bitbucket), where he explains why pulling
Russel's change causes an explosion
Hi,
has the version 2.3.1 officially been released yet? I see the packages
on Sourceforge and the docs on the web page, but I miss the official
Announce email.
Some of my friends also watch the project via Twitter. Can someone post
a short message there?
Best regards,
Dirk
On 03.03.2014 20:37, Bill Deegan wrote:
Anatoly,
This is a bikeshed'ing type discussion.
So we'll never agree on this.
The project has long had the emacs/vim info in each source file, so
there's no reason to change.
That said, some automated checking in buildbot might not be a bad idea.
On 19.02.2014 06:15, Bill Deegan wrote:
Anatoly,
bootstrap.py is not meant to be run by users, only developers.
-Bill
I'd even go one step further and say: it's primarily meant to be run by
release managers.
It's okay if you take on this role for yourself as a developer while
you're
On 19.02.2014 18:07, Bill Deegan wrote:
Might I suggest we stop discussing it and just propose pull requests.
If you have a specific change in mind, then make it and send a pull
request.
Yup, I'm all for it. @Anatoly: the commits that introduced the new doc
toolchain are 8ca01af:0c9c8af
Hi Anatoly,
On 18.02.2014 05:46, anatoly techtonik wrote:
Why SCons bootstrap became dependent on external libraries?
I find it a major usability regression. Can this be fixed?
it didn't suddenly become dependent, it always was. We're now using
DocBook, so we need to process and transform
On 18.02.2014 12:12, anatoly techtonik wrote:
[...]
There is a mistake. The bootstrap process never require documentation tools
to be present.
Correct, the bootstrap process doesn't require doc tools...but the
SConstruct at the top-level does. So unless you call bootstrap.py from
the
On 18.02.2014 19:59, anatoly techtonik wrote:
[...]
You need to ensure that there are no warnings during the build process
and the warning about missing documentation build is among those that
you especially should not ignore as a release manager. ;)
I could live with both variants for the
On 19.02.2014 00:00, anatoly techtonik wrote:
On Tue, Feb 18, 2014 at 11:50 PM, Dirk Bächle tshor...@gmx.de wrote:
On 18.02.2014 21:19, anatoly techtonik wrote:
[...]
Ok. I'll put it the other way. Between automating the job of release
manager,
which is done once in few months and automating
On 19.02.2014 00:14, anatoly techtonik wrote:
On Wed, Feb 19, 2014 at 2:08 AM, Dirk Bächle tshor...@gmx.de wrote:
[...]
Okay, and when you have a simple SConstruct in a folder like
/tmp/sconstest, change into this folder via cd /tmp/sconstest and then
call
python /full/path/to/scons/repo
Hi Russel,
On 15.02.2014 08:40, Russel Winder wrote:
On Thu, 2014-02-13 at 16:20 -0500, Gary Oberbrunner wrote:
Thanks to Manuel Naranjo, our application is now in. Please go to
http://www.scons.org/wiki/GSoC2014Ideas (which is just a clone of the 2013
ideas page so far) and add/edit/cleanup.
On 13.02.2014 21:43, Gary Oberbrunner wrote:
Hey, it works for me too!
Okay, I created pull request #109, fixing this issue. Check and merge it
when you find the time...and don't stress yourself out on the 2.3.1
release. This is still supposed to feel like fun, not work. ;)
Dirk
the package (which doesn't work right
now btw), that would be awesome.
-Bill
On Mon, Feb 3, 2014 at 12:07 PM, Dirk Bächle tshor...@gmx.de
mailto:tshor...@gmx.de wrote:
On 03.02.2014 20:05, Gary Oberbrunner wrote:
Hi folks; if we want to get a GSoC project this year, now's
the time
Hi Gary,
On 02.02.2014 23:13, Gary Oberbrunner wrote:
HA -- got a small repro testcase!
[...]
Run that twice as scons all-defuns.obj. The second time _shouldn't_
rebuild anything, but it will re-run the Copy command. SCons 2.3.0
correctly doesn't do anything the second time.
looks
On 12.02.2014 00:29, Dirk Bächle wrote:
[...]
This let's your simple testcase pass on my side...
Uppss, please replace with:
This lets...
:)
Dirk
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
On 11.02.2014 05:57, William Deegan wrote:
http://beta.slashdot.org/story/198003
That's cool news...would it make sense to send them a short note,
thanking them for choosing SCons, and offering them help on our user
mailing list if they need it?
Dirk
On 03.02.2014 20:05, Gary Oberbrunner wrote:
Hi folks; if we want to get a GSoC project this year, now's the time
to think about it.
Top of my priority list for a GSoC student would be someone to convert
everything to python3, finishing what we've started already. Other ideas?
Looking
On 02.02.2014 23:13, Gary Oberbrunner wrote:
HA -- got a small repro testcase!
[...]
Dirk, I guess the ball's in your court! :-) Of course I want to keep
helping to solve it but at least you and interested others (hi
Roberto!) can give it a try.
Thanks a lot for the testcase. I'll have
On 28.01.2014 23:57, Gary Oberbrunner wrote:
More results, no fix yet.
The generated file all-defuns.c I mentioned before is definitely part
of the problem. I back-ported the tracing code I wrote to just before
Dirk's memory optimization. In that version, near the beginning of
the build
On 21.01.2014 19:05, Russel Winder wrote:
I just ran all the test on Debian Unstable and got 70 no results, which
seems fine, but 9 test fails. 2 of these I understand, the others I have
no clue about:
test/Docbook/basedir/htmlchunked/htmlchunked_cmd.py
On 21.01.2014 18:39, Russel Winder wrote:
It is clearly the case that TestSCons.TestSCons().where_is(toolSequence)
uses the users current PATH to search. However when the tool is actually
used, the stripped down PATH is used. This means there appears to be no
way of checking whether a test will
On 13.01.2014 20:18, Gary Oberbrunner wrote:
Dirk, and others: I tracked down my spurious rebuild to the addition
of caching changed-status in File.changed() in Node/FS.py. If I
remove that caching code I don't get the rebuilds:
diff --git a/src/engine/SCons/Node/FS.py
On 10.01.2014 18:46, Kenny, Jason L wrote:
I have the same issue with the build at my job. I thought it might
have been bug in Parts passing data around, a badly define build files
that dependson stuff differently if something exists on disk or not (
ie something that is built). However I
On 09.01.2014 14:55, Gary Oberbrunner wrote:
I'm also getting some spurious rebuilds with 2.3.1 compared with
2.3.0. Will dig into it. Dirk, I'm not sure if it's your patch or
something else that changed.
Gary,
I created a pull request, switching off the memory savings for the
Hi Roberto,
On 08.01.2014 22:52, Gary Oberbrunner wrote:
On Wed, Jan 8, 2014 at 4:49 PM, roberto de vecchi
roberto.devec...@vi-grade.com mailto:roberto.devec...@vi-grade.com
wrote:
Gary,
I think that the problem I'm seeing is generated by the
modification in FS.py around line
Bill,
On 17.12.2013 22:06, Bill Deegan wrote:
Dirk,
If the memory patch uses __slots, then won't that likely break some
user logic? If so then we should push out 2.3.1 without it with a
notice in the release notes indicating what such change may break?
this patch doesn't use slots at
Hi Jason,
and thanks for chiming in.
On 28.10.2013 17:07, Kenny, Jason L wrote:
I hope I would not be a wrench in engine :-)
Honestly The issue that this is work and I have to do this at home is the main
reason I have not pushed anything at this point. ( And having twin 3 years-old
means I
Hi,
over the last few days I had another look at SCons' speed and memory
problems. As posted in an earlier email, I am able to reduce the maximum
amount of memory used during runtime (both, clean and update builds) by
up to 50% in large C/CPP projects.
This is reached by freeing infos in the
201 - 300 of 351 matches
Mail list logo
