success. I wonder what the regular expression was :)
2008/10/6 Christopher Sean Morrison <[EMAIL PROTECTED]>: > > > Take #5. Still debugging with sf.net staff. New datacenter so maybe this > one will finally make it through.. > > > On Sunday, August 24, 2008, at 02:54AM, "Christopher Sean Morrison" <[EMAIL > PROTECTED]> wrote: >> >>Feel free to ignore this message if it makes it through. I'm >>debugging a mailing list issue with the Sourceforge staff. The >>message apparently matches some "pharma ban" regular expression >>blacklist spam filter on sf.net mail system (before it even gets to >>mailman). >> >> >> > ---------- Forwarded message ---------- >> > From: Dawn Thomas <[EMAIL PROTECTED]> >> > Date: 2008/6/30 >> > Subject: [brlcad-devel] gsoc: Libpc >> > To: John Anderson <[EMAIL PROTECTED]> >> > Cc: [EMAIL PROTECTED] >> > >> > >> > Dear John, >> > As you would have seen in the repository, I have integrated Boost >> > Graphics Library ( :) and corrected that crappy build break ) . I >>have >> > implemented also the basic binary constraint solving framework. The >> > current solver doesnt work since there is no backtracking. I am a >> > few days away from completing a fully functional binary constraint >> > solver. By functional I imply a solver which returns all solutions of >> > the constraint with proper representation of ranges of variables in >> > case of multiple solutions. >> > >> > Regarding BGL, as of now i am using only their data structure and >> > access mechanisms and none of their algorithmic support. I have also >> > enabled postscript support via graphviz /dot so as to check the >>graphs >> > generated < http://parametrics.files.wordpress.com/2008/06/x.png>I >> > think when we actually deal with non binary constraints ( next on >> > agenda after I finish the work on binary constraint solver and the >> > remaining part of the C code ( dbio, params, pc_set ) and in >> > particular hypergraphs/bipartite graphs, such template algorithms and >> > in particular visitor<> based extensions of bgl template algorithms >> > would be important. >> > >> > I am also writing most of the parts as template classes so that later >> > we could use it for generic constraint solving as well if required. >> > Though it is really far away i guess. Geometry constraint solving and >> > representation is a tough job in itself. >> >> >> >> If the constraints are stored as objects in the database file, >> >> they will need names (as I see you already know). Do you intend >> >> for the constraint object names to be exposed to the users? If >> >> not, a method could be developed to provides unique names that are >> >> not likely to collide with user created names. I guess this could >> >> be addressed in a UI developed later. >> >> >> > My intention was not to expose the constraint object names to the >> > users. I mean a user does not stand to gain much from that >> > information. We could write a random name generator. I am still >> > thinking about how to represent the constraints / list of constraints >> > in the UI. >> > Should it be that the user provides a command such as >> > >> > #listconstraints sph1 >> > would provide a list of constraints >> > eg. >> > >> > 1. tangency with box2 >> > 2. radius = 30 >> > 3. centre = apex of cone3 >> > In such a situation to support editing we can straightaway give users >> > access to the constraint object names or we can provide a >> > functionality such as >> > >> > #constredit sph1%1 >> > or some similar character for % implying edit tangency with box2 >> > >> > I somehow find both the methods rather unsatisfactory. >> >> >> >> I suspect the solving of the constraints will need to be >> >> triggered in a few places. Obviously, some command in MGED to run >> >> the constraint solver. Also in rt, to get the constraints >> >> evaluated prior to raytracing. I suspect this should be done in >> >> "rt_gettree_leaf" (tree.c in librt) before the prep routine of the >> >> primitive is called (or perhaps from the prep routine itself). >> >> >> > I was thinking of calling it from the prep routine itself. I am not >> > sure if some of the specific checking needs using the constraint >> > solver functionality. Regarding interaction with mged, my idea was >> > that we invoke the constraint solver by some particular command which >> > generates the solution if it exists . If multiple solutions exist, it >> > informs the user of the same asking him to support particular set of >> > values within the domain solution ( or select an optimal solution if >> > the user chooses so) This would be followed by solver/mged calling >>the >> > geometry update functionality which will update the geometry whose >> > parameters have changed as well as other geometry associated with >> > these. >> > >> > Sincerely yours, >> > >> > >> > >> > >> > >> > -- >> > Dawn Thomas >> > IIT Kharagpur >> > >> > " the strength to change what i can, the inability to accept what i >> > can't, and the incapacity to tell the difference" >> >> >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > BRL-CAD Developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > -- Dawn Thomas IIT Kharagpur " the strength to change what i can, the inability to accept what i can't, and the incapacity to tell the difference" ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
