00:04.10 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
00:33.43 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
00:36.29 |
Notify |
03BRL-CAD:starseeker * 69233
brlcad/trunk/src/other/libnetpbm/CMakeLists.txt: correct spelling
of project name |
00:55.32 |
Notify |
03BRL-CAD:starseeker * 69234
brlcad/trunk/src/librt/db5_size.cpp: Make the mi vars local to
match the main import function |
01:02.31 |
Notify |
03BRL-CAD:starseeker * 69235
(brlcad/trunk/INSTALL brlcad/trunk/configure and 3 others): Add lz4
to src/other and enable use in librt cache. Untested on
Windows |
01:37.32 |
Notify |
03BRL-CAD:starseeker * 69236
brlcad/trunk/src/librt/comb/db_comb.c: The problem was actually
with _db_comb_get_children. Because the array was built backwards,
a failed db_lookup was adding a terminating RT_DIR_NULL earlier in
the array. Number of leaves is not the same as number of valid
leaves. Check ahead of time and handle the invalid case so we get
what is expected. |
01:42.29 |
Notify |
03BRL-CAD:starseeker * 69237
brlcad/trunk/src/librt/db5_size.cpp: Go ahead and check in the
commented out test code comparing the two means of getting children
of a comb in case we need to try this again later. This special
purpose version, although fast, can not replace the comb internal
tree walking version since routines processing the internal form
assume the comb is already fully cracked and populated in |
01:42.31 |
Notify |
standard memory structures. This general
approach could be highly instructive when it comes to optimizing
the db_search logic however, since that operates at the directory
pointer level. Worth thinking about. |
01:42.33 |
Notify |
... |
01:44.07 |
*** join/#brlcad ca_
(b497c0f8@gateway/web/freenode/ip.180.151.192.248) |
01:44.38 |
ca_ |
does anyone have a minute? |
01:44.57 |
Stragus |
Just ask your question directly |
01:45.10 |
ca_ |
okay, i need help setting up brlcad on a
mac |
01:45.27 |
ca_ |
im using an mged file |
01:45.44 |
ca_ |
and it says "This window should automatically
close within 5 seconds" |
01:46.47 |
*** join/#brlcad
xyaqnsalqkqawdoe
(~armin@dslb-088-064-039-075.088.064.pools.vodafone-ip.de) |
01:48.03 |
Stragus |
Mmhm. Stick around a little, I'm sure brlcad
or someone else will be able to offer some guidance |
01:48.31 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
01:51.08 |
Notify |
03BRL-CAD:starseeker * 69238
brlcad/trunk/src/librt/db5_size.cpp: Attributes are always checked
regardless - don't need to check separately for solids |
01:51.59 |
Notify |
03BRL-CAD:starseeker * 69239
brlcad/trunk/src/librt/db5_size.cpp: So far in testing sorting
doesn't pay for itself even with large models. |
02:02.43 |
Notify |
03BRL-CAD:starseeker * 69240
brlcad/trunk/src/librt/db5_size.cpp: half the remaining time is
spent in _db5_get_attributes_size, most of that in
db_get_external_reuse |
02:24.13 |
Notify |
03BRL-CAD:starseeker * 69241
brlcad/trunk/src/librt/db5_size.cpp: If we've alredy done the
extern lookup for the attributes, reuse it rather than looking it
up again for the comb. |
04:08.55 |
*** join/#brlcad PranavGarg
(a9958d3d@gateway/web/freenode/ip.169.149.141.61) |
04:36.25 |
*** join/#brlcad thegreat
(a9958d3d@gateway/web/freenode/ip.169.149.141.61) |
05:00.43 |
*** join/#brlcad Lord_of_Codes
(~Lord_of_C@122.163.244.145) |
06:12.59 |
*** join/#brlcad amarjeet
(~amarjeet@202.164.53.117) |
06:28.45 |
*** join/#brlcad thegreat
(a995942b@gateway/web/freenode/ip.169.149.148.43) |
06:41.08 |
*** join/#brlcad sniok
(~sniok@pc-212-191-78-204.p.lodz.pl) |
07:09.30 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-jxrbewtgudzfxgls) |
07:10.10 |
*** join/#brlcad teepee_
(~teepee@unaffiliated/teepee) |
07:17.12 |
*** join/#brlcad caen23
(~caen23@79.112.95.83) |
07:18.29 |
caen23 |
uh, what's up with the compilation tasks on
gci? does it show sept 23 because of a bug, or did they both just
download a binary? |
07:20.56 |
caen23 |
leaning towards the latter, since they seem to
have used the same versions of everything, and i see no mingw or
dev tools in their screenshots |
07:27.35 |
amarjeet |
No, student have completed or taken task
related to compilaton. They all did the task of just
running. |
07:30.27 |
amarjeet |
oh are you talking about compilation of
librecad task |
07:36.08 |
caen23 |
yes |
07:44.16 |
amarjeet |
I also think that they might have just used
binaries |
07:44.43 |
amarjeet |
https://github.com/LibreCAD/LibreCAD/blob/master/librecad/src/src.pro#L13
as it says version should be 2.2.0 |
07:46.08 |
amarjeet |
just I building it on my system with new
updates and then I would tell more |
07:46.17 |
amarjeet |
I am* |
07:46.56 |
*** join/#brlcad merzo
(~merzo@91.217.179.122) |
07:50.42 |
amarjeet |
yes, they have not build but used binaries as
its showing Version: 2.2.0-alpha-131-g0d239ca |
07:50.42 |
amarjeet |
Compiler: GNU GCC 5.4.0 |
07:50.42 |
amarjeet |
Compiled on: Nov 29 2016 |
07:50.42 |
amarjeet |
Qt Version: 5.5.1 |
07:50.42 |
amarjeet |
Boost Version: 1.58.0 |
07:50.43 |
amarjeet |
System: Ubuntu 16.04.1 LTS |
08:47.11 |
caen23 |
brlcad: i'm considering adding the memory
leaks task in the interface. should i go through with it, or wait
until a few more tasks are completed? |
09:36.05 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-npfnzwiqumxlbgte) |
09:53.43 |
*** join/#brlcad d_rossberg
(~rossberg@104.225.5.10) |
10:08.53 |
*** join/#brlcad teepee]
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
10:14.12 |
*** join/#brlcad Caterpillar
(~caterpill@unaffiliated/caterpillar) |
10:15.14 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-jxcrkoamsmdyyagv) |
10:19.16 |
*** join/#brlcad merzo
(~merzo@91.217.179.122) |
10:35.43 |
*** join/#brlcad amarjeet
(~amarjeet@202.164.53.117) |
11:06.22 |
*** join/#brlcad gongy
(~gongy@c220-239-97-230.belrs4.nsw.optusnet.com.au) |
11:06.59 |
gongy |
:( looks like website is down guys |
11:15.22 |
*** join/#brlcad gongyy
(~gongy@c220-239-97-230.belrs4.nsw.optusnet.com.au) |
11:15.46 |
gongyy |
> apologies, looks like fault from my
end. |
11:47.55 |
Notify |
03BRL-CAD:brlcad * 69242 brlcad/trunk/INSTALL:
superfluous |
12:27.12 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-umlrnjjfdgsoszkj) |
12:40.11 |
*** join/#brlcad yorik
(~yorik@2804:431:f721:47e1:290:f5ff:fedc:3bb2) |
12:54.52 |
*** join/#brlcad merzo
(~merzo@91.217.179.122) |
13:10.20 |
caen23 |
this one seems fine
https://codein.withgoogle.com/dashboard/task-instances/6330778166231040/ |
13:16.07 |
ries |
caen23: I just approved it |
13:48.52 |
*** join/#brlcad Lord_of_Codes
(~Lord_of_C@122.163.244.145) |
14:04.34 |
*** join/#brlcad amarjeet
(~amarjeet@169.149.140.166) |
14:09.50 |
brlcad |
caen23: no need to wait when adding tasks,
they sit in a queue .. i have to manually publish them |
14:50.06 |
*** join/#brlcad amarjeet
(~Amarjeet@169.149.140.166) |
14:51.44 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
15:03.56 |
*** join/#brlcad amarjeet
(~Amarjeet@169.149.140.166) |
15:39.34 |
*** join/#brlcad ankesh11
(uid8015@gateway/web/irccloud.com/x-jqqsmbrhzgquekzw) |
15:40.03 |
*** join/#brlcad ankesh11_
(uid8015@gateway/web/irccloud.com/x-paidbakdidxmnwka) |
16:41.34 |
*** join/#brlcad caen23
(~caen23@79.112.95.83) |
16:47.18 |
*** join/#brlcad amarjeet
(~amarjeet@2405:205:4109:4c10:1a2:6705:b142:9cf7) |
16:53.10 |
*** join/#brlcad amarjeet_
(~amarjeet@2405:205:4109:4c10:1a2:6705:b142:9cf7) |
17:05.54 |
*** join/#brlcad boquete___
(~Piotr@5.172.255.147) |
17:09.57 |
*** join/#brlcad amarjeet__
(~amarjeet@169.149.184.112) |
17:11.53 |
*** join/#brlcad amarjeet__
(~amarjeet@2405:205:4109:4c10:1a2:6705:b142:9cf7) |
17:25.34 |
*** join/#brlcad ickby_
(~stefan@x5d8468e6.dyn.telefonica.de) |
17:36.18 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-obmfmpxzpqugsqiu) |
17:36.49 |
*** join/#brlcad yorik
(~yorik@2804:431:f721:47e1:290:f5ff:fedc:3bb2) |
17:47.42 |
*** join/#brlcad
Lord_of_Codes_ (~Lord_of_C@122.163.244.145) |
18:14.28 |
*** join/#brlcad thecoder
(a995bb95@gateway/web/freenode/ip.169.149.187.149) |
18:50.20 |
ries |
brlcad: on a other completed item I did see :
Waiting for parental consent approval when I approved (I think hat
was my only option) I just clicked approve, is that ok? I did
verify if the task was done correctly.. |
18:50.24 |
*** join/#brlcad amarjeet
(~Amarjeet@169.149.161.225) |
19:02.27 |
*** join/#brlcad sniok
(~sniok@pc-212-191-78-204.p.lodz.pl) |
19:04.33 |
sniok |
brlcad: Hi, I think one student is copying
another student |
19:05.07 |
sniok |
https://codein.withgoogle.com/dashboard/task-instances/4795200253722624/
is similar to
https://codein.withgoogle.com/dashboard/task-instances/6314184358756352/ |
19:14.46 |
ries |
sniok: Unless I am overlooking, I donât see
the name in the command window |
19:15.11 |
ries |
can you confirm that? |
19:15.15 |
sniok |
yeah, they both lack name |
19:16.32 |
sniok |
but the latest is more suspicious, it says
28.11.2016 in screenshot and the same desktop as other
student |
19:19.09 |
ries |
sniok:
https://codein.withgoogle.com/dashboard/task-instances/6314184358756352/
is already approved, I am not sure if we can (or should) change
that |
19:19.36 |
ries |
For
https://codein.withgoogle.com/dashboard/task-instances/4795200253722624/
I added a comment and asked for adding the name in the command
window |
19:20.15 |
sniok |
alright, thanks |
19:20.45 |
ries |
np |
19:28.34 |
*** join/#brlcad Lord_of_Codes
(~Lord_of_C@122.163.244.145) |
19:36.20 |
*** join/#brlcad yorik
(~yorik@2804:431:f721:47e1:290:f5ff:fedc:3bb2) |
19:37.27 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-byonakododirdqsx) |
19:43.06 |
Notify |
03BRL-CAD:starseeker * 69243
brlcad/trunk/src/librt/db5_size.cpp: Consolidate the child logic
into a single function - for these purposes, it doesn't matter
whether the 'children' are from a comb or one of the primitives
that reference other objects. Simplifys the main loop. Primitive
specific logic other than comb untested, but trying a similar trick
to get the child name with a minimal cracking of the
extern. |
19:47.07 |
*** join/#brlcad merzo
(~merzo@93-195-113-92.pool.ukrtel.net) |
19:49.01 |
*** join/#brlcad MikeH
(~Mike@188.175.158.32) |
19:49.26 |
*** join/#brlcad MikeHan
(~Mike@188.175.158.32) |
20:00.28 |
Notify |
03BRL-CAD:starseeker * 69244
brlcad/trunk/src/librt/db5_size.cpp: remove the inner
timer. |
20:09.46 |
*** join/#brlcad ca_
(b497ef91@gateway/web/freenode/ip.180.151.239.145) |
20:44.51 |
*** join/#brlcad ickby_
(~stefan@x5d8468e6.dyn.telefonica.de) |
21:38.34 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-dmqoddjfoteymhov) |
22:09.25 |
*** join/#brlcad ishwerdas
(7cfd7052@gateway/web/cgi-irc/kiwiirc.com/ip.124.253.112.82) |
22:25.11 |
Notify |
03BRL-CAD:starseeker * 69245
brlcad/trunk/src/librt/librt_private.h: Fix Windows
build. |
23:07.28 |
starseeker |
brlcad: what do you think about putting a
timestamp in the directory structure? It wouldn't need to be
something that had to be written to disk, as long as it got
initialized when the .g was opened and updated whenever the
directory object was written |
23:08.06 |
starseeker |
I need a way to tell when an object has been
changed, and that seems like the simplest approach |
23:21.54 |
*** join/#brlcad teepee_
(~teepee@unaffiliated/teepee) |
23:23.17 |
*** join/#brlcad Caterpillar2
(~caterpill@unaffiliated/caterpillar) |
23:29.09 |
*** join/#brlcad merzo
(~merzo@93-195-113-92.pool.ukrtel.net) |
23:36.24 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-ywpvkjwyqwyhilue) |