You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(4) |
Feb
(2) |
Mar
(7) |
Apr
(2) |
May
(2) |
Jun
(8) |
Jul
|
Aug
(4) |
Sep
(3) |
Oct
(10) |
Nov
(1) |
Dec
(10) |
2006 |
Jan
(6) |
Feb
(2) |
Mar
(4) |
Apr
(6) |
May
(21) |
Jun
(8) |
Jul
(3) |
Aug
(7) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
2007 |
Jan
(2) |
Feb
(5) |
Mar
(5) |
Apr
(3) |
May
(2) |
Jun
(1) |
Jul
(9) |
Aug
|
Sep
(4) |
Oct
(5) |
Nov
|
Dec
(2) |
2008 |
Jan
(3) |
Feb
(1) |
Mar
(15) |
Apr
(10) |
May
(11) |
Jun
(31) |
Jul
(16) |
Aug
(71) |
Sep
(15) |
Oct
(7) |
Nov
(15) |
Dec
|
2009 |
Jan
(8) |
Feb
(4) |
Mar
(44) |
Apr
(36) |
May
(14) |
Jun
(30) |
Jul
(19) |
Aug
(1) |
Sep
(5) |
Oct
(2) |
Nov
(5) |
Dec
(10) |
2010 |
Jan
(19) |
Feb
(21) |
Mar
(1) |
Apr
(38) |
May
(10) |
Jun
(8) |
Jul
(1) |
Aug
(23) |
Sep
(30) |
Oct
(19) |
Nov
(4) |
Dec
(13) |
2011 |
Jan
(129) |
Feb
(51) |
Mar
(39) |
Apr
(20) |
May
(12) |
Jun
(30) |
Jul
(38) |
Aug
(24) |
Sep
(164) |
Oct
(92) |
Nov
(33) |
Dec
(27) |
2012 |
Jan
(77) |
Feb
(29) |
Mar
(251) |
Apr
(159) |
May
(219) |
Jun
(142) |
Jul
(180) |
Aug
(50) |
Sep
(4) |
Oct
(7) |
Nov
(45) |
Dec
(22) |
2013 |
Jan
(16) |
Feb
(6) |
Mar
(34) |
Apr
(211) |
May
(97) |
Jun
(95) |
Jul
(219) |
Aug
(170) |
Sep
(175) |
Oct
(191) |
Nov
(78) |
Dec
(90) |
2014 |
Jan
(77) |
Feb
(84) |
Mar
(232) |
Apr
(56) |
May
(110) |
Jun
(97) |
Jul
(69) |
Aug
(58) |
Sep
(54) |
Oct
(76) |
Nov
(53) |
Dec
(30) |
2015 |
Jan
(28) |
Feb
(22) |
Mar
(268) |
Apr
(54) |
May
(66) |
Jun
(90) |
Jul
(75) |
Aug
(61) |
Sep
(4) |
Oct
(5) |
Nov
(41) |
Dec
(3) |
2016 |
Jan
(5) |
Feb
(40) |
Mar
(422) |
Apr
(33) |
May
(74) |
Jun
(80) |
Jul
(43) |
Aug
(79) |
Sep
(12) |
Oct
(8) |
Nov
(39) |
Dec
|
2017 |
Jan
(7) |
Feb
(10) |
Mar
(99) |
Apr
(63) |
May
(36) |
Jun
(65) |
Jul
(104) |
Aug
(66) |
Sep
(40) |
Oct
(46) |
Nov
(17) |
Dec
(16) |
2018 |
Jan
(3) |
Feb
(25) |
Mar
(58) |
Apr
(16) |
May
(22) |
Jun
(12) |
Jul
(14) |
Aug
(13) |
Sep
(1) |
Oct
(3) |
Nov
(14) |
Dec
(7) |
2019 |
Jan
(3) |
Feb
(6) |
Mar
(15) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(5) |
Oct
(9) |
Nov
(6) |
Dec
(1) |
2020 |
Jan
(1) |
Feb
(5) |
Mar
(37) |
Apr
(4) |
May
(3) |
Jun
(6) |
Jul
(7) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2021 |
Jan
(16) |
Feb
(7) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
2022 |
Jan
(8) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Vasco C. <vas...@gm...> - 2022-03-27 18:18:27
|
Ok, thanks! I am afraid without at least a minimum of financing I will not be able to devote much time to this project in the near future. Inflation is bad enough as it is. And it will get worse. Regards, On Sun, Mar 27, 2022 at 6:43 PM Daniel Roßberg <dan...@gm...> wrote: > Hello Vasco, > > There was a similar question on the GSoC mailing list recently: > > https://groups.google.com/g/google-summer-of-code-discuss/c/B4XFJIJ__gA/m/JHGoRYWtBAAJ > If you can't access the link, the answer was "Correct, you are not > eligible to be a GSoC contributor in 2022 if you were a GSoC student > back in 2019." > > I don't want to keep you from working on the OpenCL port, but I'm > afraid that you can't do this as a GSoC contributor. > > Regards, > Daniel > > Am So., 27. März 2022 um 04:32 Uhr schrieb Vasco Costa < > vas...@gm...>: > > > > Hello, > > I am interested in continuing work to finish the main bottlenecks in the > BRL-CAD OpenCL port. > > These would be, I think, NURBS, plate triangles, and Pipe primitives > render support. > > > > I already participated in GSoC as a student once several years back. So > this would be my second time. > > > > From what I understand I do not be enrolled as a student to participate > this year. But what is this that you need to be a newbie to open source? If > you can apply two times for GSoC, how can you even even apply a second time > at all? You won't be a newbie to open source then right? > > > > Regards, > > > > -- > > Vasco Alexandre da Silva Costa > > PhD in Computer Engineering (Computer Graphics) > > Instituto Superior Técnico/University of Lisbon, Portugal > > _______________________________________________ > > BRL-CAD Developer mailing list > > brl...@li... > > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > > > _______________________________________________ > BRL-CAD Developer mailing list > brl...@li... > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > -- Vasco Alexandre da Silva Costa PhD in Computer Engineering (Computer Graphics) Instituto Superior Técnico/University of Lisbon, Portugal |
From: Daniel R. <dan...@gm...> - 2022-03-27 17:43:30
|
Hello Vasco, There was a similar question on the GSoC mailing list recently: https://groups.google.com/g/google-summer-of-code-discuss/c/B4XFJIJ__gA/m/JHGoRYWtBAAJ If you can't access the link, the answer was "Correct, you are not eligible to be a GSoC contributor in 2022 if you were a GSoC student back in 2019." I don't want to keep you from working on the OpenCL port, but I'm afraid that you can't do this as a GSoC contributor. Regards, Daniel Am So., 27. März 2022 um 04:32 Uhr schrieb Vasco Costa <vas...@gm...>: > > Hello, > I am interested in continuing work to finish the main bottlenecks in the BRL-CAD OpenCL port. > These would be, I think, NURBS, plate triangles, and Pipe primitives render support. > > I already participated in GSoC as a student once several years back. So this would be my second time. > > From what I understand I do not be enrolled as a student to participate this year. But what is this that you need to be a newbie to open source? If you can apply two times for GSoC, how can you even even apply a second time at all? You won't be a newbie to open source then right? > > Regards, > > -- > Vasco Alexandre da Silva Costa > PhD in Computer Engineering (Computer Graphics) > Instituto Superior Técnico/University of Lisbon, Portugal > _______________________________________________ > BRL-CAD Developer mailing list > brl...@li... > https://lists.sourceforge.net/lists/listinfo/brlcad-devel |
From: Vasco C. <vas...@gm...> - 2022-03-27 02:31:52
|
Hello, I am interested in continuing work to finish the main bottlenecks in the BRL-CAD OpenCL port. These would be, I think, NURBS, plate triangles, and Pipe primitives render support. I already participated in GSoC as a student once several years back. So this would be my second time. >From what I understand I do not be enrolled as a student to participate this year. But what is this that you need to be a newbie to open source? If you can apply two times for GSoC, how can you even even apply a second time at all? You won't be a newbie to open source then right? Regards, -- Vasco Alexandre da Silva Costa PhD in Computer Engineering (Computer Graphics) Instituto Superior Técnico/University of Lisbon, Portugal |
From: Christopher S. M. <br...@ma...> - 2022-01-13 06:25:38
|
Hey Tom! > Sean and Cliff, Happy New Year! Pardon my intrusion but I couldn't resist. (I still fancy building a Raku (formerly known as Perl 6) interface with BRL-CAD.) Never an intrusion; discussion is always welcome! I was just working with some students this past fall on an attributes project, and the subject of your binary attributes work came up, spent some time reviewing where things were left off with your efforts. > This thread is interesting. I didn't realize the old emails were around. Quite a few years ago I searched through all I could find to look for the "off-by-one bug" I found in late 1993 or early 1994 when I started working for ASI in Fort Walton and was assigned to work with BRL-CAD. That bug report was strictly by email corresponce as I recall (in fact, I may have even written a letter to ARL to document the problem). I was a real C newbie, having come from Sun FORTRAN to SGI C. At the time I was looking to see if I could beat you at the earliest bug find! The emails are indeed (partially) preserved. There are several replies to your emails are in there.. Looks like the oldest preserved is a cited reply where you suggested in ‘93 an XYZ coordinate system orientation aid in the lower right corner. Another interesting exchange happened in '94 where you asked: a quick qestion (sic) for a novice -- what do i need to use the "html" files? Several responded with an explanation of what the “Mosaic” web browser was, how to get it, how to compile it. Hah! Such an interesting lens on pre-world-wide-web days. Cheers! Sean > P.S. My granddson is 9 and a half now. Pretty smart but more interested in Minecraft, ice hockey, an lacraosse than learning Raku (or C). Your daughter is probably a programming rock star by now! p.s. That’s fantastic! I’m finding it to be such a precious time myself. Minecraft notwithstanding, kids have access to SO many things these days. |
From: Tom B. <tom...@gm...> - 2022-01-13 00:30:04
|
On Wed, Jan 12, 2022 at 15:27 Christopher Sean Morrison via brlcad-devel < brl...@li...> wrote: ... As Cliff said, the repo has essentially everything and has been migrated to > git. It is by known accounts the world’s oldest continuously developed > repo with a commit history going back to the early 80’s. > Sean and Cliff, Happy New Year! Pardon my intrusion but I couldn't resist. (I still fancy building a Raku (formerly known as Perl 6) interface with BRL-CAD.) This thread is interesting. I didn't realize the old emails were around. Quite a few years ago I searched through all I could find to look for the "off-by-one bug" I found in late 1993 or early 1994 when I started working for ASI in Fort Walton and was assigned to work with BRL-CAD. That bug report was strictly by email corresponce as I recall (in fact, I may have even written a letter to ARL to document the problem). I was a real C newbie, having come from Sun FORTRAN to SGI C. At the time I was looking to see if I could beat you at the earliest bug find! Cheers! -Tom P.S. My granddson is 9 and a half now. Pretty smart but more interested in Minecraft, ice hockey, an lacraosse than learning Raku (or C). Your daughter is probably a programming rock star by now! |
From: Vasco C. <vas...@gm...> - 2022-01-12 23:39:10
|
Back then people would just discuss bugs or features on the mailing lists. Developers would at best keep a TODO and BUGS text file to remember important things they wanted to do/needed to fix. Things were also a lot less intense since the Internet had a lot less people. If you even had Internet access in the first place. None of this dozens or hundreds of people communicating with developers thing. That is why bug trackers are so relevant today and back then people usually did not bother. On Wed, Jan 12, 2022 at 11:20 PM Christopher Sean Morrison via brlcad-devel <brl...@li...> wrote: > Douglas, > > On Jan 12, 2022, at 5:31 PM, willful merriment via brlcad-devel < > brl...@li...> wrote: > > > thank you so much for your reply. Yes, for me the term change set would > correlate to a revision in a repository. I don't have the SVN change long > in front of me but yes it seems that 1984 is about the BOT for the repo. > It is the time starting from something like 1979 on I was asking about. As > to the SVN change log, the typical comments are "one line change", "spider > pig crawls", "depreciated"... > > > Don’t really agree with the characterization that those are typical (if > one can even summarize anything across 80,000 commits as being “typical”), > but shorter less helpful messages were more common dev practice prior to > 2004. Since then, you’ll find such commit messages are quite rare. > > The project goes back to 1979 but version control systems do not. CVS > came into existence in 1990. RCS around the time of our repo, 1982 I > think. There may have been some things in SCCS during the VAX/PDP days, > but such nuance is lost to time. Is there a reason you’re looking to go > back that far? > > You do realize how exceptionally rare it is to find a project that has > preserved history across revision control systems back this far? You seem > to be applying modern standards about 20 years too many… :) > > If it’s to understand origins, BRL-CAD’s were/are extensively documented > in formal publications, reports, and presentations. That was how things > were done back then. This may help: > https://brlcad.org/BRL-CAD_Bibliography.pdf > > Most of those are available online or can be accessed in a library. > > As to reading the changes and inferring the intended affect, that seems > obviously backwards. Yes git can show that graphically, but gets no one > any closer to understanding the motivation for the change. In my > experience the bugs list is indispensable in understanding the motivation > for the change, steps needed to replicate a problem and often discussions > between developers. > > > No bug tracking system goes back as far as our sources, so what you’re > hoping for simply was not a thing in the 80’s. Prior to GitHub and general > issue trackers, circa 2000, it was not at all common to use bug report > interfaces for discussion, understanding, or requirements traceability. As > I mentioned earlier, there are trackers on SourceForge and they will get > you back to around 2004-2018 with issues, feature requests, and bugs > tracked and discussed separately. There is also loads of documentation in > the aforementioned bibliography. > > Mailing lists were also common in the late 80’s early 90’s for design > discussion and BRL-CAD’s email archives are also in the repository in the > doc/ directory. > > If you have specific questions about the code or a given commit, please > feel free to ask. > > Cheers! > Sean > > > _______________________________________________ > BRL-CAD Developer mailing list > brl...@li... > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > -- Vasco Alexandre da Silva Costa PhD in Computer Engineering (Computer Graphics) Instituto Superior Técnico/University of Lisbon, Portugal |
From: Christopher S. M. <br...@ma...> - 2022-01-12 23:19:58
|
Douglas, > On Jan 12, 2022, at 5:31 PM, willful merriment via brlcad-devel <brl...@li...> wrote: > > thank you so much for your reply. Yes, for me the term change set would correlate to a revision in a repository. I don't have the SVN change long in front of me but yes it seems that 1984 is about the BOT for the repo. It is the time starting from something like 1979 on I was asking about. As to the SVN change log, the typical comments are "one line change", "spider pig crawls", "depreciated"... Don’t really agree with the characterization that those are typical (if one can even summarize anything across 80,000 commits as being “typical”), but shorter less helpful messages were more common dev practice prior to 2004. Since then, you’ll find such commit messages are quite rare. The project goes back to 1979 but version control systems do not. CVS came into existence in 1990. RCS around the time of our repo, 1982 I think. There may have been some things in SCCS during the VAX/PDP days, but such nuance is lost to time. Is there a reason you’re looking to go back that far? You do realize how exceptionally rare it is to find a project that has preserved history across revision control systems back this far? You seem to be applying modern standards about 20 years too many… :) If it’s to understand origins, BRL-CAD’s were/are extensively documented in formal publications, reports, and presentations. That was how things were done back then. This may help: https://brlcad.org/BRL-CAD_Bibliography.pdf Most of those are available online or can be accessed in a library. > As to reading the changes and inferring the intended affect, that seems obviously backwards. Yes git can show that graphically, but gets no one any closer to understanding the motivation for the change. In my experience the bugs list is indispensable in understanding the motivation for the change, steps needed to replicate a problem and often discussions between developers. No bug tracking system goes back as far as our sources, so what you’re hoping for simply was not a thing in the 80’s. Prior to GitHub and general issue trackers, circa 2000, it was not at all common to use bug report interfaces for discussion, understanding, or requirements traceability. As I mentioned earlier, there are trackers on SourceForge and they will get you back to around 2004-2018 with issues, feature requests, and bugs tracked and discussed separately. There is also loads of documentation in the aforementioned bibliography. Mailing lists were also common in the late 80’s early 90’s for design discussion and BRL-CAD’s email archives are also in the repository in the doc/ directory. If you have specific questions about the code or a given commit, please feel free to ask. Cheers! Sean |
From: willful m. <mer...@ya...> - 2022-01-12 22:31:04
|
Cliff, thank you so much for your reply. Yes, for me the term change set would correlate to a revision in a repository. I don't have the SVN change long in front of me but yes it seems that 1984 is about the BOT for the repo. It is the time starting from something like 1979 on I was asking about. As to the SVN change log, the typical comments are "one line change", "spider pig crawls", "depreciated"... As to reading the changes and inferring the intended affect, that seems obviously backwards. Yes git can show that graphically, but gets no one any closer to understanding the motivation for the change. In my experience the bugs list is indispensable in understanding the motivation for the change, steps needed to replicate a problem and often discussions between developers. It seems this is a dead end... BestDouglas On Wednesday, January 12, 2022, 12:23:35 PM MST, Clifford Yapp <cli...@gm...> wrote: We've actually migrated to Git and github now: https://github.com/BRL-CAD/brlcad I'm not quite sure I understand your question - our CVS repository is our older history and does still exist, but SVN has that history imported and our current Git history preserves our full CVS and SVN history all the way back to the beginning in 1984 so you should be able to see everything there. Our BUGS and TODO files are where we keep notes on problems and/or things we want to work on. For each commit (what I think you're referring to as a change set?), your best source of information is typically the commit message itself, together with an inspection of what the changes were - the gitk graphical interface is quite useful for viewing this information. Cliff On Wed, Jan 12, 2022 at 11:06 AM willful merriment via brlcad-devel <brl...@li...> wrote: Good morning brl-cad, I'm about to scratch a long standing brl-cad itch and embark on some hacking sessions. I've cloned the SVN repo as one step: now I'd like to explore two other possibilities. Is there an organized repo predating the stuff in SVN? Is there a bugs database which correlates to the SVN changes which would help me understand the motivation or goal or relationship between the change sets? Assuming such an animal exists, can I get a picture of it? Thanks for your time BestDouglas_______________________________________________ BRL-CAD Developer mailing list brl...@li... https://lists.sourceforge.net/lists/listinfo/brlcad-devel _______________________________________________ BRL-CAD Developer mailing list brl...@li... https://lists.sourceforge.net/lists/listinfo/brlcad-devel |
From: Christopher S. M. <br...@ma...> - 2022-01-12 21:26:42
|
> On Jan 12, 2022, at 11:07 AM, willful merriment via brlcad-devel <brl...@li...> wrote: > > > Good morning brl-cad, > > I'm about to scratch a long standing brl-cad itch and embark on some hacking sessions. I've cloned the SVN repo as one step: now I'd like to explore two other possibilities. Is there an organized repo predating the stuff in SVN? Is there a bugs database which correlates to the SVN changes which would help me understand the motivation or goal or relationship between the change sets? Assuming such an animal exists, can I get a picture of it? Hi Douglas, As Cliff said, the repo has essentially everything and has been migrated to git. It is by known accounts the world’s oldest continuously developed repo with a commit history going back to the early 80’s. As for understanding, see the commit log and release notes (ie NEWS file). As for bugs, there is a BUGS file for informal reports and a bug tracker still on Sourceforge. Cheers! Sean |
From: Clifford Y. <cli...@gm...> - 2022-01-12 19:23:21
|
We've actually migrated to Git and github now: https://github.com/BRL-CAD/brlcad I'm not quite sure I understand your question - our CVS repository is our older history and does still exist, but SVN has that history imported and our current Git history preserves our full CVS and SVN history all the way back to the beginning in 1984 so you should be able to see everything there. Our BUGS and TODO files are where we keep notes on problems and/or things we want to work on. For each commit (what I think you're referring to as a change set?), your best source of information is typically the commit message itself, together with an inspection of what the changes were - the gitk graphical interface is quite useful for viewing this information. Cliff On Wed, Jan 12, 2022 at 11:06 AM willful merriment via brlcad-devel < brl...@li...> wrote: > Good morning brl-cad, > > I'm about to scratch a long standing brl-cad itch and embark on some > hacking sessions. I've cloned the SVN repo as one step: now I'd like to > explore two other possibilities. Is there an organized repo predating the > stuff in SVN? Is there a bugs database which correlates to the SVN changes > which would help me understand the motivation or goal or relationship > between the change sets? Assuming such an animal exists, can I get a > picture of it? > > Thanks for your time > > Best > Douglas > _______________________________________________ > BRL-CAD Developer mailing list > brl...@li... > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > |
From: willful m. <mer...@ya...> - 2022-01-12 16:06:23
|
Good morning brl-cad, I'm about to scratch a long standing brl-cad itch and embark on some hacking sessions. I've cloned the SVN repo as one step: now I'd like to explore two other possibilities. Is there an organized repo predating the stuff in SVN? Is there a bugs database which correlates to the SVN changes which would help me understand the motivation or goal or relationship between the change sets? Assuming such an animal exists, can I get a picture of it? Thanks for your time BestDouglas |
From: Christopher S. M. <br...@ma...> - 2021-12-06 16:21:57
|
Hi Connor, No, the application is terminating (gracefully) because of the unexpected condition. MGED is halted. Again, it’s doing that because it was unable to write the file (if you run “pwd”, you’ll likely see that your working directory is a read-only location like Program Files). In later versions, that was made not a halting error and your starting location is automatically changed to a read-write location (your home directory, I believe). Cheers, Sean > On Dec 6, 2021, at 11:10 AM, Dilgren, Connor <cdi...@be...> wrote: > > Thanks Sean! Indents worked for me. > > When you say that MGED is exiting, do you mean it’s being replaced by another program? If so what is it being replaced with? > > Connor > > From: Christopher Sean Morrison <br...@ma...> > Sent: Friday, December 3, 2021 5:10 PM > To: Dilgren, Connor <cdi...@be...> > Cc: brl...@li... > Subject: Re: regions command > > Hi Conner, > > I just looked into the log and was reminded about the ptbl error your screenshot showed. That is indeed a bug that was fixed last year. > > The issue was caused by trying to write a file out to a read-only directory, so you can work around the crash by specifying a full path to a read-write location where you want the file written (e.g., regions C:/output.txt object). > > Cheers! > Sean > > > > On Dec 3, 2021, at 5:48 PM, Christopher Sean Morrison <br...@ma... <mailto:br...@ma...>> wrote: > > Hi Conner, > > I cannot reproduce the error you’re seeing. If you can e-mail me your .g file, I could look into that in more detail. I did notice that you’re using a version from a couple years ago. MGED is exiting because it encountered corrupted polygonal geometry unexpectedly. > > That said, there’s several ways to get at what you’re wanting in addition to the regions command. There’s the idents command, which will produce an even more succinct file of all regions. The usage is identical to regions: idents file object > > Another command is the search command. It’s a very powerful and flexible command: > > Finding all regions in a .g file is done easily with: search . -type region > Or to get a listing of all objects under a combination: search ./object -type region > Or to get full path listings of all objects under a combination: search /object -type region > > Cheers! > Sean > > > On Dec 3, 2021, at 11:38 AM, Dilgren, Connor <cdi...@be... <mailto:cdi...@be...>> wrote: > > Hello, > > I would like to get a file that lists all of the regions contained within an object. I’m trying to use the ‘regions’ command, as described in https://brlcad.org/~nouhrasofat/mann/en/regions.php <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbrlcad.org%2F~nouhrasofat%2Fmann%2Fen%2Fregions.php&data=04%7C01%7Ccdilgren%40bellflight.com%7Cd9958a85efb042f596d108d9b6b209d3%7C2d5b202c8c074168a55166f570d429b3%7C0%7C0%7C637741698049669691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fUAlnwLektlkQpvdMI36fiHaW6uN2a86QDKyL%2FN226g%3D&reserved=0> > > When I try to use it, I get this message: > > <image001.png> > > MGED then crashes after I hit ‘OK’. > > Am I using the command wrong, or is this a bug? Is there a different command that I should be using to get a list of the regions contained within an object? > > CONNOR DILGREN > Survivability Engineer | Bell > > Office: +1-817-280-2018 > Mobile: +1-832-683-6468 > > bellflight.com <http://www.bellflight.com/> > Follow Us @bellflight > > > <image004.png> > > If you received this transmission in error, please advise the sender by immediate reply and destroy the original transmission and its attachments. |
From: Christopher S. M. <br...@ma...> - 2021-12-03 23:10:10
|
Hi Conner, I just looked into the log and was reminded about the ptbl error your screenshot showed. That is indeed a bug that was fixed last year. The issue was caused by trying to write a file out to a read-only directory, so you can work around the crash by specifying a full path to a read-write location where you want the file written (e.g., regions C:/output.txt object). Cheers! Sean > On Dec 3, 2021, at 5:48 PM, Christopher Sean Morrison <br...@ma...> wrote: > > Hi Conner, > > I cannot reproduce the error you’re seeing. If you can e-mail me your .g file, I could look into that in more detail. I did notice that you’re using a version from a couple years ago. MGED is exiting because it encountered corrupted polygonal geometry unexpectedly. > > That said, there’s several ways to get at what you’re wanting in addition to the regions command. There’s the idents command, which will produce an even more succinct file of all regions. The usage is identical to regions: idents file object > > Another command is the search command. It’s a very powerful and flexible command: > > Finding all regions in a .g file is done easily with: search . -type region > Or to get a listing of all objects under a combination: search ./object -type region > Or to get full path listings of all objects under a combination: search /object -type region > > Cheers! > Sean > > >> On Dec 3, 2021, at 11:38 AM, Dilgren, Connor <cdi...@be... <mailto:cdi...@be...>> wrote: >> >> Hello, >> >> I would like to get a file that lists all of the regions contained within an object. I’m trying to use the ‘regions’ command, as described in https://brlcad.org/~nouhrasofat/mann/en/regions.php <https://brlcad.org/~nouhrasofat/mann/en/regions.php> >> >> When I try to use it, I get this message: >> >> <image001.png> >> >> MGED then crashes after I hit ‘OK’. >> >> Am I using the command wrong, or is this a bug? Is there a different command that I should be using to get a list of the regions contained within an object? >> >> CONNOR DILGREN >> Survivability Engineer | Bell >> >> Office: +1-817-280-2018 >> Mobile: +1-832-683-6468 >> >> bellflight.com <http://www.bellflight.com/> >> Follow Us @bellflight >> >> >> <image004.png> >> >> If you received this transmission in error, please advise the sender by immediate reply and destroy the original transmission and its attachments. > |
From: Christopher S. M. <br...@ma...> - 2021-12-03 23:05:02
|
Hi Conner, I cannot reproduce the error you’re seeing. If you can e-mail me your .g file, I could look into that in more detail. I did notice that you’re using a version from a couple years ago. MGED is exiting because it encountered corrupted polygonal geometry unexpectedly. That said, there’s several ways to get at what you’re wanting in addition to the regions command. There’s the idents command, which will produce an even more succinct file of all regions. The usage is identical to regions: idents file object Another command is the search command. It’s a very powerful and flexible command: Finding all regions in a .g file is done easily with: search . -type region Or to get a listing of all objects under a combination: search ./object -type region Or to get full path listings of all objects under a combination: search /object -type region Cheers! Sean > On Dec 3, 2021, at 11:38 AM, Dilgren, Connor <cdi...@be...> wrote: > > Hello, > > I would like to get a file that lists all of the regions contained within an object. I’m trying to use the ‘regions’ command, as described in https://brlcad.org/~nouhrasofat/mann/en/regions.php <https://brlcad.org/~nouhrasofat/mann/en/regions.php> > > When I try to use it, I get this message: > > <image001.png> > > MGED then crashes after I hit ‘OK’. > > Am I using the command wrong, or is this a bug? Is there a different command that I should be using to get a list of the regions contained within an object? > > CONNOR DILGREN > Survivability Engineer | Bell > > Office: +1-817-280-2018 > Mobile: +1-832-683-6468 > > bellflight.com <http://www.bellflight.com/> > Follow Us @bellflight > > > <image004.png> > > If you received this transmission in error, please advise the sender by immediate reply and destroy the original transmission and its attachments. |
From: <con...@tc...> - 2021-09-27 21:28:26
|
Hello brlcad-devel, fyi ... # The SQLite & Tcl Conference __Wednesday, November 17, 2021__ The 2nd annual SQLite & Tcl virtual conference will be held on Wednesday, November 17. The virtual event will feature a combination of curated talks and work in progress talks (WIPs). [Registration is open](https://www.eventbrite.com/e/the-sqlite-tcl-conference-st-2021-registration-168185004877)! Please visit the [SQLite & TCL conference](https://conf.tcl-lang.org/) home page to stay informed. # Call for Speakers We've made it easier to contribute by asking for shorter, less formal talks rather than requiring formal papers. - Have you done interesting work that you would like to share? - How about a cool idea that's not yet baked or just in the prototype stage but seems like something others would be interested in? We are particularly interested in new ideas, to hear about novel solutions to problems you've faced, or to see your work in progress. ## To submit your talk: Please visit the [call for speakers page](https://conf.tcl-lang.org/callforspeakers/) for instructions. As a token of our appreciation, each speaker will be gifted with a video conferencing light kit to use while presenting. The call for speakers for S&T 2021 ends on __October 4, 2021 at 11:59 PM CT__. __Important dates:__ - October 4 - Call for speakers for S&T 2021 ends at 11:59 PM CT - October 8 - We will start notifying speakers with their status of their submission and scheduled talk. - October 18 - Agenda for S&T 2021 Announced - November 17 - S&T 2021 held digitally online |
From: Christopher S. M. <br...@ma...> - 2021-03-10 17:48:39
|
BRL-CAD was once again accepted into the 2021 Google Summer of Code! This year, we are partnering as the umbrella organization with IfcOpenShell, FreeCAD, and OpenSCAD. If you would like to be a mentor, please let me know (via e-mail, zulip, irc, etc.) so I can make sure you’re set up. If you’re an interested student, please check out our project ideas: https://github.com/opencax/GSoC/issues?q=is%3Aissue+is%3Aopen+label%3A%22GSoC+2021%22+label%3A%22Project%3A+BRL-CAD%22 <https://github.com/opencax/GSoC/issues?q=is:issue+is:open+label:%22GSoC+2021%22+label:%22Project:+BRL-CAD%22> A continuation of any previous BRL-CAD GSoC project is also a viable project. There are links for all previous years at: http://brlcad.org/wiki/Google_Summer_of_Code <http://brlcad.org/wiki/Google_Summer_of_Code> Come talk with us on Zulip for interactive discussion at https://brlcad.zulipchat.com <https://brlcad.zulipchat.com/> Cheers! Sean |
From: Rob M. <rob...@gm...> - 2021-03-09 21:05:03
|
Thanks much for all the info. I will take a bit to digest everything. Not sure if you support this functionality already -- but it would likely be a piece of cake for you. I once had need to use RT techniques to figure out solar visibility and equivalent area for a solar aircraft from every view angle. Visibility is determined by shadowing / occluding. Then there is another term that takes into account the angle between the light ray and the solar panel normal vector that calculates a knock-down factor for refraction through the glass. The final answer is given in terms of equivalent area. Most who do this use a point source for the sun, but with sophisticated ray tracing, you could include the effect of the umbra too. Best, Rob On Tue, Mar 9, 2021 at 12:00 PM Christopher Sean Morrison via brlcad-devel < brl...@li...> wrote: > > On Mar 9, 2021, at 1:50 AM, Rob McDonald <rob...@gm...> wrote: > > Thanks Sean, that is exactly what I was looking for. The output from > rtedge looks great. > > Is there any documentation of the edge detection algorithms applied in > rtedge? It is done as a raster, do you know if it can be done as a vector > instead? > > > It is currently performed as a raster operation, operating at a specified > resolution, but it certainly could be done in vector space instead. Note > that while the output is raster, the edge detection is not exactly > happening in raster space. It happens in the 3D space via ray tracing > taking things like surface curvature, material properties, depth > differences, and unique objects into consideration. The manual page > explains in a bit more detail (running “man rtedge” in mged or archer or > running “brlman rtedge” on the system command line will display relevant > documentation. > > Vector output is definitely something we’ve talked about implementing, but > have yet to do so. There’s a couple approaches that come to mind that > wouldn’t be terribly difficult. First approach could be to limit > consideration to explicit geometry such as NURBS or polygonal meshes where > you evaluate a 2D projection of the geometry. Second approach that isn’t > limited would be to perform adaptive refinement over the existing 2D raster > method to evaluate projected curve connectivity. There are a number of > papers and implementations that have demonstrated both can work rather well. > > I went to try to look for the code. I must admit, I couldn't really > figure out where to start looking. I'm also on a Mac -- would using 7.24.0 > pose any problems for playing with this? I'd like to be able to read a > STEP or IGES file and then see what rtedge produces. > > > There’s some detail and references, including pointers to the existing > code for rtedge, available at > https://brlcad.org/wiki/Vector_Drawings_from_NURBS > > Obviously, longer term I'm looking to steal good ideas and implement them > natively in OpenVSP. We don't have any sort of ray tracing engine, so our > implementation will have to be considerably different. > > > The most common uses case for BRL-CAD is as an embedded solid ray-tracing > engine. The LIBRT ray tracing library could be integrated into OpenVSP > where geometry is (trasnparently to the user) passed to librt or rtedge and > rasterized to a hidden-line rendering. We could even create a high-level > image rendering library to help simplify the process depending on your > needs. > > Cheers! > Sean > > _______________________________________________ > BRL-CAD Developer mailing list > brl...@li... > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > |
From: Christopher S. M. <br...@ma...> - 2021-03-09 20:00:29
|
> On Mar 9, 2021, at 1:50 AM, Rob McDonald <rob...@gm...> wrote: > > Thanks Sean, that is exactly what I was looking for. The output from rtedge looks great. > > Is there any documentation of the edge detection algorithms applied in rtedge? It is done as a raster, do you know if it can be done as a vector instead? It is currently performed as a raster operation, operating at a specified resolution, but it certainly could be done in vector space instead. Note that while the output is raster, the edge detection is not exactly happening in raster space. It happens in the 3D space via ray tracing taking things like surface curvature, material properties, depth differences, and unique objects into consideration. The manual page explains in a bit more detail (running “man rtedge” in mged or archer or running “brlman rtedge” on the system command line will display relevant documentation. Vector output is definitely something we’ve talked about implementing, but have yet to do so. There’s a couple approaches that come to mind that wouldn’t be terribly difficult. First approach could be to limit consideration to explicit geometry such as NURBS or polygonal meshes where you evaluate a 2D projection of the geometry. Second approach that isn’t limited would be to perform adaptive refinement over the existing 2D raster method to evaluate projected curve connectivity. There are a number of papers and implementations that have demonstrated both can work rather well. > I went to try to look for the code. I must admit, I couldn't really figure out where to start looking. I'm also on a Mac -- would using 7.24.0 pose any problems for playing with this? I'd like to be able to read a STEP or IGES file and then see what rtedge produces. There’s some detail and references, including pointers to the existing code for rtedge, available at https://brlcad.org/wiki/Vector_Drawings_from_NURBS <https://brlcad.org/wiki/Vector_Drawings_from_NURBS> > Obviously, longer term I'm looking to steal good ideas and implement them natively in OpenVSP. We don't have any sort of ray tracing engine, so our implementation will have to be considerably different. The most common uses case for BRL-CAD is as an embedded solid ray-tracing engine. The LIBRT ray tracing library could be integrated into OpenVSP where geometry is (trasnparently to the user) passed to librt or rtedge and rasterized to a hidden-line rendering. We could even create a high-level image rendering library to help simplify the process depending on your needs. Cheers! Sean |
From: Rob M. <rob...@gm...> - 2021-03-09 06:51:08
|
Thanks Sean, that is exactly what I was looking for. The output from rtedge looks great. Is there any documentation of the edge detection algorithms applied in rtedge? It is done as a raster, do you know if it can be done as a vector instead? I went to try to look for the code. I must admit, I couldn't really figure out where to start looking. I'm also on a Mac -- would using 7.24.0 pose any problems for playing with this? I'd like to be able to read a STEP or IGES file and then see what rtedge produces. Obviously, longer term I'm looking to steal good ideas and implement them natively in OpenVSP. We don't have any sort of ray tracing engine, so our implementation will have to be considerably different. Rob On Mon, Mar 8, 2021 at 9:09 PM Christopher Sean Morrison via brlcad-devel < brl...@li...> wrote: > Rob, > > BRL-CAD includes an application called “rtedge” that produces rasterized > hidden line edge drawings. These can be useful standalone as a foundation > for diagrams and blueprinting, or they can be overlaid over shaded > renderings. Here are a couple examples: > > https://www.facebook.com/brlcad/photos/10155080800198873/ > *https://brlcad.org/gallery/galleries/renderings/bradley_rtwizard.jpg > <https://brlcad.org/gallery/galleries/renderings/bradley_rtwizard.jpg>* > > There are related tools and features for other styles, such a generating a > silhouette projection or generating flat-shaded rendering, plus a suite of > tools that will post-process in image space (e.g., to quantize colors or > color replacements and much more). > > Cheers! > Sean > > > On Mar 8, 2021, at 8:21 PM, Rob McDonald <rob...@gm...> wrote: > > What does BRL-CAD do in terms of NPR rendering? > > I'm not thinking particularly artistic forms of NPR, but mainly extracting > feature lines on the fly. > > In OpenVSP, I have a few heuristics that create a few feature lines, but > there are others that we don't generate -- and some that are there don't > really add much to the view. > > I've read a bunch of papers about purely OpenGL based approaches -- while > fast, those don't let you 'keep' the lines for output to a drawing (vector > file) or whatnot. > > All this made me wonder what BRL-CAD does in this area. > > Best, > > Rob > _______________________________________________ > BRL-CAD Developer mailing list > brl...@li... > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > > > _______________________________________________ > BRL-CAD Developer mailing list > brl...@li... > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > |
From: Christopher S. M. <br...@ma...> - 2021-03-09 05:09:45
|
Rob, BRL-CAD includes an application called “rtedge” that produces rasterized hidden line edge drawings. These can be useful standalone as a foundation for diagrams and blueprinting, or they can be overlaid over shaded renderings. Here are a couple examples: https://www.facebook.com/brlcad/photos/10155080800198873/ <https://www.facebook.com/brlcad/photos/10155080800198873/> https://brlcad.org/gallery/galleries/renderings/bradley_rtwizard.jpg There are related tools and features for other styles, such a generating a silhouette projection or generating flat-shaded rendering, plus a suite of tools that will post-process in image space (e.g., to quantize colors or color replacements and much more). Cheers! Sean > On Mar 8, 2021, at 8:21 PM, Rob McDonald <rob...@gm...> wrote: > > What does BRL-CAD do in terms of NPR rendering? > > I'm not thinking particularly artistic forms of NPR, but mainly extracting feature lines on the fly. > > In OpenVSP, I have a few heuristics that create a few feature lines, but there are others that we don't generate -- and some that are there don't really add much to the view. > > I've read a bunch of papers about purely OpenGL based approaches -- while fast, those don't let you 'keep' the lines for output to a drawing (vector file) or whatnot. > > All this made me wonder what BRL-CAD does in this area. > > Best, > > Rob > _______________________________________________ > BRL-CAD Developer mailing list > brl...@li... > https://lists.sourceforge.net/lists/listinfo/brlcad-devel |
From: Rob M. <rob...@gm...> - 2021-03-09 01:22:02
|
What does BRL-CAD do in terms of NPR rendering? I'm not thinking particularly artistic forms of NPR, but mainly extracting feature lines on the fly. In OpenVSP, I have a few heuristics that create a few feature lines, but there are others that we don't generate -- and some that are there don't really add much to the view. I've read a bunch of papers about purely OpenGL based approaches -- while fast, those don't let you 'keep' the lines for output to a drawing (vector file) or whatnot. All this made me wonder what BRL-CAD does in this area. Best, Rob |
From: Daniel R. <dan...@gm...> - 2021-02-16 15:29:12
|
Compilation works with the current CMake version. Regards, Daniel Am Do., 11. Feb. 2021 um 11:48 Uhr schrieb Daniel Roßberg < dan...@gm...>: > Confirmed. > > The set_property() statements are a bit different in this CMakeLists.txt > file: APPEND vs. APPEND_STRING > "If the APPEND option is given the list is appended to any existing > property value (except that empty values are ignored and not appended). If > the APPEND_STRING option is given the string is appended to any existing > property value as string, i.e. it results in a longer string and not a list > of strings." > > However, I'll try again with current CMake binaries. > > Regards, > Daniel > > Am Mi., 10. Feb. 2021 um 16:46 Uhr schrieb Clifford Yapp < > cli...@gm...>: > >> So, to confirm you're seeing the line: >> >> 32.2/include";CFG_RUNTIME_DOCDIR="C:/Program Files/BRL-CAD >> 7.32.2/share/man"-Ot -Oi >> >> Checking my output, it looks like: >> >> 32.2/include";CFG_RUNTIME_DOCDIR="C:/Program Files/BRL-CAD >> 7.32.2/share/man";-Ot -Oi >> >> Those flags are coming from this line (src/other/tcl/CMakeLists.txt:115): >> >> set_property(SOURCE ${srcfile} APPEND_STRING PROPERTY COMPILE_DEFINITIONS >> "-Ot -Oi -fp:strict -Gs -GS -GL -MD") >> >> My first suggestion would be to try a newer CMake version and see if that >> addresses it. >> >> Cliff >> >> On Wed, Feb 10, 2021 at 5:32 AM Daniel Roßberg <dan...@gm...> >> wrote: >> >>> Yes, clean checkout and new created build directory. CMake version is >>> 3.15.4. >>> >>> The bug is visible in the tcl.vcxproj file: In the lines containing >>> CFG_RUNTIME_DOCDIR, a semicolon is missing after the directory string. If >>> you have it with your version, I'll try again with an updated CMake. >>> (Unfortunately, it can happen that I can't update it before next Monday.) >>> >>> Regards, >>> Daniel >>> >>> Am Mi., 10. Feb. 2021 um 00:05 Uhr schrieb Clifford Yapp < >>> cli...@gm...>: >>> >>>> Is that with a clean build directory? Also, which version of CMake? >>>> >>>> I also built with VS2019, so it's curious that that configuration >>>> should fail... >>>> >>>> >>>> On Tue, Feb 9, 2021 at 10:44 AM Daniel Roßberg < >>>> dan...@gm...> wrote: >>>> >>>>> Hmm, my Visual Studio 2019 build fails, Release, sources from >>>>> branches/RELEASE, plain CMake run (nothing changed). >>>>> Error in src/other/tcl/generic/tclPkgConfig.c, line 107. The >>>>> CFG_RUNTIME_DOCDIR makro looks bad. It includes compiler switches after >>>>> the path string. They aren't cleanly separated (at least for Visual >>>>> Studio). >>>>> >>>>> Regards >>>>> Daniel >>>>> >>>>> Am Sa., 6. Feb. 2021 um 15:33 Uhr schrieb Clifford Yapp < >>>>> cli...@gm...>: >>>>> >>>>>> Release preparations are underway. Trunk sources merged to the >>>>>> RELEASE branch will be reviewed for sync to STABLE and release tagging. >>>>>> Please help test by compiling distcheck-full and running benchmark, mged, >>>>>> and archer. >>>>>> _______________________________________________ >>>>>> BRL-CAD Developer mailing list >>>>>> brl...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>>>>> >>>>> _______________________________________________ >>>>> BRL-CAD Developer mailing list >>>>> brl...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>>>> >>>> _______________________________________________ >>>> BRL-CAD Developer mailing list >>>> brl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>>> >>> _______________________________________________ >>> BRL-CAD Developer mailing list >>> brl...@li... >>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>> >> _______________________________________________ >> BRL-CAD Developer mailing list >> brl...@li... >> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >> > |
From: Daniel R. <dan...@gm...> - 2021-02-11 10:49:25
|
Confirmed. The set_property() statements are a bit different in this CMakeLists.txt file: APPEND vs. APPEND_STRING "If the APPEND option is given the list is appended to any existing property value (except that empty values are ignored and not appended). If the APPEND_STRING option is given the string is appended to any existing property value as string, i.e. it results in a longer string and not a list of strings." However, I'll try again with current CMake binaries. Regards, Daniel Am Mi., 10. Feb. 2021 um 16:46 Uhr schrieb Clifford Yapp < cli...@gm...>: > So, to confirm you're seeing the line: > > 32.2/include";CFG_RUNTIME_DOCDIR="C:/Program Files/BRL-CAD > 7.32.2/share/man"-Ot -Oi > > Checking my output, it looks like: > > 32.2/include";CFG_RUNTIME_DOCDIR="C:/Program Files/BRL-CAD > 7.32.2/share/man";-Ot -Oi > > Those flags are coming from this line (src/other/tcl/CMakeLists.txt:115): > > set_property(SOURCE ${srcfile} APPEND_STRING PROPERTY COMPILE_DEFINITIONS > "-Ot -Oi -fp:strict -Gs -GS -GL -MD") > > My first suggestion would be to try a newer CMake version and see if that > addresses it. > > Cliff > > On Wed, Feb 10, 2021 at 5:32 AM Daniel Roßberg <dan...@gm...> > wrote: > >> Yes, clean checkout and new created build directory. CMake version is >> 3.15.4. >> >> The bug is visible in the tcl.vcxproj file: In the lines containing >> CFG_RUNTIME_DOCDIR, a semicolon is missing after the directory string. If >> you have it with your version, I'll try again with an updated CMake. >> (Unfortunately, it can happen that I can't update it before next Monday.) >> >> Regards, >> Daniel >> >> Am Mi., 10. Feb. 2021 um 00:05 Uhr schrieb Clifford Yapp < >> cli...@gm...>: >> >>> Is that with a clean build directory? Also, which version of CMake? >>> >>> I also built with VS2019, so it's curious that that configuration should >>> fail... >>> >>> >>> On Tue, Feb 9, 2021 at 10:44 AM Daniel Roßberg < >>> dan...@gm...> wrote: >>> >>>> Hmm, my Visual Studio 2019 build fails, Release, sources from >>>> branches/RELEASE, plain CMake run (nothing changed). >>>> Error in src/other/tcl/generic/tclPkgConfig.c, line 107. The >>>> CFG_RUNTIME_DOCDIR makro looks bad. It includes compiler switches after >>>> the path string. They aren't cleanly separated (at least for Visual >>>> Studio). >>>> >>>> Regards >>>> Daniel >>>> >>>> Am Sa., 6. Feb. 2021 um 15:33 Uhr schrieb Clifford Yapp < >>>> cli...@gm...>: >>>> >>>>> Release preparations are underway. Trunk sources merged to the >>>>> RELEASE branch will be reviewed for sync to STABLE and release tagging. >>>>> Please help test by compiling distcheck-full and running benchmark, mged, >>>>> and archer. >>>>> _______________________________________________ >>>>> BRL-CAD Developer mailing list >>>>> brl...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>>>> >>>> _______________________________________________ >>>> BRL-CAD Developer mailing list >>>> brl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>>> >>> _______________________________________________ >>> BRL-CAD Developer mailing list >>> brl...@li... >>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>> >> _______________________________________________ >> BRL-CAD Developer mailing list >> brl...@li... >> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >> > _______________________________________________ > BRL-CAD Developer mailing list > brl...@li... > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > |
From: Clifford Y. <cli...@gm...> - 2021-02-10 15:45:50
|
So, to confirm you're seeing the line: 32.2/include";CFG_RUNTIME_DOCDIR="C:/Program Files/BRL-CAD 7.32.2/share/man"-Ot -Oi Checking my output, it looks like: 32.2/include";CFG_RUNTIME_DOCDIR="C:/Program Files/BRL-CAD 7.32.2/share/man";-Ot -Oi Those flags are coming from this line (src/other/tcl/CMakeLists.txt:115): set_property(SOURCE ${srcfile} APPEND_STRING PROPERTY COMPILE_DEFINITIONS "-Ot -Oi -fp:strict -Gs -GS -GL -MD") My first suggestion would be to try a newer CMake version and see if that addresses it. Cliff On Wed, Feb 10, 2021 at 5:32 AM Daniel Roßberg <dan...@gm...> wrote: > Yes, clean checkout and new created build directory. CMake version is > 3.15.4. > > The bug is visible in the tcl.vcxproj file: In the lines containing > CFG_RUNTIME_DOCDIR, a semicolon is missing after the directory string. If > you have it with your version, I'll try again with an updated CMake. > (Unfortunately, it can happen that I can't update it before next Monday.) > > Regards, > Daniel > > Am Mi., 10. Feb. 2021 um 00:05 Uhr schrieb Clifford Yapp < > cli...@gm...>: > >> Is that with a clean build directory? Also, which version of CMake? >> >> I also built with VS2019, so it's curious that that configuration should >> fail... >> >> >> On Tue, Feb 9, 2021 at 10:44 AM Daniel Roßberg <dan...@gm...> >> wrote: >> >>> Hmm, my Visual Studio 2019 build fails, Release, sources from >>> branches/RELEASE, plain CMake run (nothing changed). >>> Error in src/other/tcl/generic/tclPkgConfig.c, line 107. The >>> CFG_RUNTIME_DOCDIR makro looks bad. It includes compiler switches after >>> the path string. They aren't cleanly separated (at least for Visual >>> Studio). >>> >>> Regards >>> Daniel >>> >>> Am Sa., 6. Feb. 2021 um 15:33 Uhr schrieb Clifford Yapp < >>> cli...@gm...>: >>> >>>> Release preparations are underway. Trunk sources merged to the RELEASE >>>> branch will be reviewed for sync to STABLE and release tagging. Please >>>> help test by compiling distcheck-full and running benchmark, mged, and >>>> archer. >>>> _______________________________________________ >>>> BRL-CAD Developer mailing list >>>> brl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>>> >>> _______________________________________________ >>> BRL-CAD Developer mailing list >>> brl...@li... >>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>> >> _______________________________________________ >> BRL-CAD Developer mailing list >> brl...@li... >> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >> > _______________________________________________ > BRL-CAD Developer mailing list > brl...@li... > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > |
From: Daniel R. <dan...@gm...> - 2021-02-10 10:32:30
|
Yes, clean checkout and new created build directory. CMake version is 3.15.4. The bug is visible in the tcl.vcxproj file: In the lines containing CFG_RUNTIME_DOCDIR, a semicolon is missing after the directory string. If you have it with your version, I'll try again with an updated CMake. (Unfortunately, it can happen that I can't update it before next Monday.) Regards, Daniel Am Mi., 10. Feb. 2021 um 00:05 Uhr schrieb Clifford Yapp < cli...@gm...>: > Is that with a clean build directory? Also, which version of CMake? > > I also built with VS2019, so it's curious that that configuration should > fail... > > > On Tue, Feb 9, 2021 at 10:44 AM Daniel Roßberg <dan...@gm...> > wrote: > >> Hmm, my Visual Studio 2019 build fails, Release, sources from >> branches/RELEASE, plain CMake run (nothing changed). >> Error in src/other/tcl/generic/tclPkgConfig.c, line 107. The >> CFG_RUNTIME_DOCDIR makro looks bad. It includes compiler switches after >> the path string. They aren't cleanly separated (at least for Visual >> Studio). >> >> Regards >> Daniel >> >> Am Sa., 6. Feb. 2021 um 15:33 Uhr schrieb Clifford Yapp < >> cli...@gm...>: >> >>> Release preparations are underway. Trunk sources merged to the RELEASE >>> branch will be reviewed for sync to STABLE and release tagging. Please >>> help test by compiling distcheck-full and running benchmark, mged, and >>> archer. >>> _______________________________________________ >>> BRL-CAD Developer mailing list >>> brl...@li... >>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>> >> _______________________________________________ >> BRL-CAD Developer mailing list >> brl...@li... >> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >> > _______________________________________________ > BRL-CAD Developer mailing list > brl...@li... > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > |