www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Helix and CanDyDOC release

reply Victor Nakoryakov <Victor_member pathlink.com> writes:
Hi all.

I've upload something named Helix recently. Actualy this is two projects. First
is Helix itself - applied mathematics routines library. It's small right now,
but will grow with time.

The second thing is something that I hope will be intresting for biger audience:
CanDyDOC. It is a set of .ddoc, .js and other files that provides ability to
generate advanced documentation htmls.

Learn more at http://trac.dsource.org/projects/helix/wiki and
http://trac.dsource.org/projects/helix/wiki/CandyDoc

There are few bugs in CanDyDOC and there are not all features I planned to do
are done. So for now CanDyDOC is my first priority. Any ideas and proposals are
welcome in project's forum.

--
Victor (aka nail) Nakoryakov
nail-mail[at]mail.ru

Krasnoznamensk, Moscow, Russi
Feb 22 2006
next sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Victor Nakoryakov skrev:


 CanDyDOC. It is a set of .ddoc, .js and other files that provides ability to
 generate advanced documentation htmls.


I am really impressed. Nice work!

/Oskar
Feb 22 2006
prev sibling next sibling parent "Charles" <noone nowhere.com> writes:
Im totally amazed.  This is better than any documentation ive ever seen!!

And I love the name!

"Victor Nakoryakov" <Victor_member pathlink.com> wrote in message
news:dti0su$2b9i$1 digitaldaemon.com...

 Hi all.

 I've upload something named Helix recently. Actualy this is two projects.


First

 is Helix itself - applied mathematics routines library. It's small right


now,

 but will grow with time.

 The second thing is something that I hope will be intresting for biger


audience:

 CanDyDOC. It is a set of .ddoc, .js and other files that provides ability


to

 generate advanced documentation htmls.

 Learn more at http://trac.dsource.org/projects/helix/wiki and
 http://trac.dsource.org/projects/helix/wiki/CandyDoc

 There are few bugs in CanDyDOC and there are not all features I planned to


do

 are done. So for now CanDyDOC is my first priority. Any ideas and


proposals are

 welcome in project's forum.

 --
 Victor (aka nail) Nakoryakov
 nail-mail[at]mail.ru

 Krasnoznamensk, Moscow, Russi
Feb 22 2006
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <dti0su$2b9i$1 digitaldaemon.com>, Victor Nakoryakov says...

Hi all.

I've upload something named Helix recently. Actualy this is two projects. First
is Helix itself - applied mathematics routines library. It's small right now,
but will grow with time.

The second thing is something that I hope will be intresting for biger audience:
CanDyDOC. It is a set of .ddoc, .js and other files that provides ability to
generate advanced documentation htmls.

Learn more at http://trac.dsource.org/projects/helix/wiki and
http://trac.dsource.org/projects/helix/wiki/CandyDoc

There are few bugs in CanDyDOC and there are not all features I planned to do
are done. So for now CanDyDOC is my first priority. Any ideas and proposals are
welcome in project's forum.

--
Victor (aka nail) Nakoryakov
nail-mail[at]mail.ru

Krasnoznamensk, Moscow, Russi


Victor, I like the screenshots, and the .ddoc code is really quite
self-explanitory.  Plus your HTML/JS/CSS code is impeccable.  Great Job!

Out of curiosity, do you have any ideas or concepts as how to handle
cross-references within .ddoc generated documentation?  I've traveled all the
way down the XML/XSLT data path from .ddoc to get something hacked together, but
maybe you have a more elegant solution in mind?

- Eric Anderton at yahoo
Feb 22 2006
parent reply Victor Nakoryakov <nail-mail mail.ru> writes:
pragma wrote:

 In article <dti0su$2b9i$1 digitaldaemon.com>, Victor Nakoryakov says...
 

Hi all.

I've upload something named Helix recently. Actualy this is two projects. First
is Helix itself - applied mathematics routines library. It's small right now,
but will grow with time.

The second thing is something that I hope will be intresting for biger audience:
CanDyDOC. It is a set of .ddoc, .js and other files that provides ability to
generate advanced documentation htmls.

Learn more at http://trac.dsource.org/projects/helix/wiki and
http://trac.dsource.org/projects/helix/wiki/CandyDoc

There are few bugs in CanDyDOC and there are not all features I planned to do
are done. So for now CanDyDOC is my first priority. Any ideas and proposals are
welcome in project's forum.

--
Victor (aka nail) Nakoryakov
nail-mail[at]mail.ru

Krasnoznamensk, Moscow, Russi


 
 
 Victor, I like the screenshots, and the .ddoc code is really quite
 self-explanitory.  Plus your HTML/JS/CSS code is impeccable.  Great Job!


Thanx


 Out of curiosity, do you have any ideas or concepts as how to handle
 cross-references within .ddoc generated documentation?  I've traveled all the
 way down the XML/XSLT data path from .ddoc to get something hacked together,
but
 maybe you have a more elegant solution in mind?


I have clean vision on how to done something like 'bla bla bla see also 
$(REF mypackage.mymodule.myclass.mymethod)'. It can be acheived with 
some js tricks, and it is planned to done in next versions. Or did you 
mean something else like automatic reference in comments like 'bla bla 
bla see also mypackage.mymodule.myclass.mymethod', if so I have no ideas.


 - Eric Anderton at yahoo


BTW. I think automatic references and decisions are evil. In practice of 
documenting few thouthands lines of code I noticed that in 90% of cases 
I have to prepend words that is the same as currently described 
declaration name with _ to avoid their's highlighting. I think it is 
better to explicitly specify that I want word highlighting with macro or 
with enclosing it in backquotes for example.


-- 
Victor (aka nail) Nakoryakov
nail-mail [at] mail.ru

Krasnoznamensk, Moscow, Russia
Feb 22 2006
parent reply pragma <pragma_member pathlink.com> writes:
In article <dtiqmf$alg$1 digitaldaemon.com>, Victor Nakoryakov says...

pragma wrote:

 Out of curiosity, do you have any ideas or concepts as how to handle
 cross-references within .ddoc generated documentation?  I've traveled all the
 way down the XML/XSLT data path from .ddoc to get something hacked together,
but
 maybe you have a more elegant solution in mind?


I have clean vision on how to done something like 'bla bla bla see also 
$(REF mypackage.mymodule.myclass.mymethod)'. It can be acheived with 
some js tricks, and it is planned to done in next versions. Or did you 
mean something else like automatic reference in comments like 'bla bla 
bla see also mypackage.mymodule.myclass.mymethod', if so I have no ideas.


 - Eric Anderton at yahoo


BTW. I think automatic references and decisions are evil. In practice of 
documenting few thouthands lines of code I noticed that in 90% of cases 
I have to prepend words that is the same as currently described 
declaration name with _ to avoid their's highlighting. I think it is 
better to explicitly specify that I want word highlighting with macro or 
with enclosing it in backquotes for example.


Actually I was referring to something more like what javadoc output does, where
each platform and user defined type (in method signatures and declarations) is a
link to the referenced type.  I've learned that the ddoc output scheme makes
this a very hard problem to solve, and I was curious if you'd given it any
thought.

- Eric Anderton at yahoo
Feb 22 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
pragma wrote:

 In article <dtiqmf$alg$1 digitaldaemon.com>, Victor Nakoryakov says...

 pragma wrote:

 Out of curiosity, do you have any ideas or concepts as how to handle
 cross-references within .ddoc generated documentation?  I've traveled all the
 way down the XML/XSLT data path from .ddoc to get something hacked together,
but
 maybe you have a more elegant solution in mind?


 I have clean vision on how to done something like 'bla bla bla see also 
 $(REF mypackage.mymodule.myclass.mymethod)'. It can be acheived with 
 some js tricks, and it is planned to done in next versions. Or did you 
 mean something else like automatic reference in comments like 'bla bla 
 bla see also mypackage.mymodule.myclass.mymethod', if so I have no ideas.


 - Eric Anderton at yahoo


 BTW. I think automatic references and decisions are evil. In practice of 
 documenting few thouthands lines of code I noticed that in 90% of cases 
 I have to prepend words that is the same as currently described 
 declaration name with _ to avoid their's highlighting. I think it is 
 better to explicitly specify that I want word highlighting with macro or 
 with enclosing it in backquotes for example.


 
 Actually I was referring to something more like what javadoc output does, where
 each platform and user defined type (in method signatures and declarations) is
a
 link to the referenced type.  I've learned that the ddoc output scheme makes
 this a very hard problem to solve, and I was curious if you'd given it any
 thought.


Maybe Walter could help here. It's pretty trivial task to do when you
have all the symbol tables, etc. at hand when generating the
documentation code. Otherwise you're going to end up doing a separate
frontend for docs.

-- 
Jari-Matti
Feb 22 2006
parent Victor Nakoryakov <nail-mail mail.ru> writes:
Jari-Matti Mäkelä wrote:

 
 
 Maybe Walter could help here. It's pretty trivial task to do when you
 have all the symbol tables, etc. at hand when generating the
 documentation code. Otherwise you're going to end up doing a separate
 frontend for docs.
 


Looks like it is an only simple (for us, not Walter :)) way to acomplish 
this. So it is necessary to have some implicit macro:

1) $(DDOC_LOOKUP MyFunction) should be expanded to something like 
mypackage.mymodule.MyTemplate.MyType.MyFunction.N where this path is 
full path to symbol passed as argument in current context and N is 
number of overload.

2) There should be redefinable macro $(DDOC_BACKQUOTE arg) which should 
be expanded when we enclose some expression (arg) in backuotes.

3) All types that are used in declarations should be implictly backuoted.

Realising this 3 requests will lead to our problem solving. But for now 
full-featured cross references is realy big task.

-- 
Victor (aka nail) Nakoryakov
nail-mail [at] mail.ru

Krasnoznamensk, Moscow, Russia
Feb 23 2006
prev sibling next sibling parent reply John Demme <me teqdruid.com> writes:
Victor Nakoryakov wrote:


 Hi all.
 
 I've upload something named Helix recently. Actualy this is two projects.
 First is Helix itself - applied mathematics routines library. It's small
 right now, but will grow with time.
 
 The second thing is something that I hope will be intresting for biger
 audience: CanDyDOC. It is a set of .ddoc, .js and other files that
 provides ability to generate advanced documentation htmls.
 
 Learn more at http://trac.dsource.org/projects/helix/wiki and
 http://trac.dsource.org/projects/helix/wiki/CandyDoc
 
 There are few bugs in CanDyDOC and there are not all features I planned to
 do are done. So for now CanDyDOC is my first priority. Any ideas and
 proposals are welcome in project's forum.
 
 --
 Victor (aka nail) Nakoryakov
 nail-mail[at]mail.ru
 
 Krasnoznamensk, Moscow, Russi



Looks great!  Does it do class dependancy charts and links to type
definitions yet?

~John Demme
Feb 22 2006
parent reply Victor Nakoryakov <nail-mail mail.ru> writes:
John Demme wrote:

 Victor Nakoryakov wrote:
 
 

Hi all.

I've upload something named Helix recently. Actualy this is two projects.
First is Helix itself - applied mathematics routines library. It's small
right now, but will grow with time.

The second thing is something that I hope will be intresting for biger
audience: CanDyDOC. It is a set of .ddoc, .js and other files that
provides ability to generate advanced documentation htmls.

Learn more at http://trac.dsource.org/projects/helix/wiki and
http://trac.dsource.org/projects/helix/wiki/CandyDoc

There are few bugs in CanDyDOC and there are not all features I planned to
do are done. So for now CanDyDOC is my first priority. Any ideas and
proposals are welcome in project's forum.

--
Victor (aka nail) Nakoryakov
nail-mail[at]mail.ru

Krasnoznamensk, Moscow, Russi


 
 
 
 Looks great!  Does it do class dependancy charts


No charts yet. I think class dependancy graphs is some heritage of 
C++/doxygen past, but module dependance charts could be useful, I'll 
think about. Anyway there are foreground tasks, so this thing can be 
done in versions after 1.0 release.


 and links to type
 definitions yet?


Ammm... what did you mean exactly?


 ~John Demme



-- 
Victor (aka nail) Nakoryakov
nail-mail [at] mail.ru

Krasnoznamensk, Moscow, Russia
Feb 22 2006
parent reply John Demme <me teqdruid.com> writes:
Victor Nakoryakov wrote:

 Looks great!  Does it do class dependancy charts


 
 No charts yet. I think class dependancy graphs is some heritage of
 C++/doxygen past, but module dependance charts could be useful, I'll
 think about. Anyway there are foreground tasks, so this thing can be
 done in versions after 1.0 release.
 

 and links to type
 definitions yet?


 
 Ammm... what did you mean exactly?
 


Essentially what I'm looking for is the ability to click my way around. 
That is, say you've got the following two classes:

class A
{
}

class B: A
{
        void foo(A bar);
}

In the documentation for class B, I want the text saying that it inherits
from A to be a link to the documentation for A.  In the documentation for
the method foo, I want a link to the documentation for A in the description
of the parameter bar... doxygen does this, and it's infinitely valuable
when looking through the Mango docs.

~John
Feb 22 2006
parent Victor Nakoryakov <nail-mail mail.ru> writes:
John Demme wrote:

 Victor Nakoryakov wrote:
 

Looks great!  Does it do class dependancy charts


No charts yet. I think class dependancy graphs is some heritage of
C++/doxygen past, but module dependance charts could be useful, I'll
think about. Anyway there are foreground tasks, so this thing can be
done in versions after 1.0 release.



and links to type
definitions yet?


Ammm... what did you mean exactly?


 
 
 Essentially what I'm looking for is the ability to click my way around. 
 That is, say you've got the following two classes:
 
 class A
 {
 }
 
 class B: A
 {
         void foo(A bar);
 }
 
 In the documentation for class B, I want the text saying that it inherits
 from A to be a link to the documentation for A.  In the documentation for
 the method foo, I want a link to the documentation for A in the description
 of the parameter bar... doxygen does this, and it's infinitely valuable
 when looking through the Mango docs.
 
 ~John



Aha,... See neighbour discussion branch.

-- 
Victor (aka nail) Nakoryakov
nail-mail [at] mail.ru

Krasnoznamensk, Moscow, Russia
Feb 23 2006
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Victor Nakoryakov" <Victor_member pathlink.com> wrote in message 
news:dti0su$2b9i$1 digitaldaemon.com...

 Hi all.

 I've upload something named Helix recently. Actualy this is two projects. 
 First
 is Helix itself - applied mathematics routines library. It's small right 
 now,
 but will grow with time.

 The second thing is something that I hope will be intresting for biger 
 audience:
 CanDyDOC. It is a set of .ddoc, .js and other files that provides ability 
 to
 generate advanced documentation htmls.

 Learn more at http://trac.dsource.org/projects/helix/wiki and
 http://trac.dsource.org/projects/helix/wiki/CandyDoc

 There are few bugs in CanDyDOC and there are not all features I planned to 
 do
 are done. So for now CanDyDOC is my first priority. Any ideas and 
 proposals are
 welcome in project's forum.


Cool, Victor.
And I like word AJAX these days :)

Andrew.



 --
 Victor (aka nail) Nakoryakov
 nail-mail[at]mail.ru

 Krasnoznamensk, Moscow, Russi
Feb 22 2006