[PD] [text define] functionality for text in structs?
Billy Stiltner
billy.stiltner at gmail.com
Fri Mar 31 14:44:19 CEST 2017
i dont like tree structures at the moment
but here ya go
void Spider(xTreeItem CurrentItem)
{
int s;
CString spaces;
CString xStr;
//There Could Probably Be More Vars Here To Save Space
//Down There... There Also Needs To Be Some Space
//Generating Loop Code Put Into A Function
//CurrentItem Is Either A Branch Or A Leaf
//The Processing Of CurrentItem Will Be Different
//For Each State Of CurrentItem
if(CurrentItem.IsBranch())
{
CString currentpath;
CString currenturl;
//Set Up All The Path Variables And File Names
//And Levels
CurrentLevel ++;
currentpath = BasePath;
currenturl = BaseURL;
CurrentItem.FileName = "index.txt";
CurrentItem.Level = CurrentLevel;
DirectoryL[CurrentLevel] = CurrentItem.Directory;
for(int l = 1; l <= CurrentLevel; l ++)
{
currentpath += "\\" + DirectoryL[l];
currenturl += "/" + DirectoryL[l];
}
CurrentItem.LocalHtmlPath=currentpath + "\\index.html";
CurrentItem.Url = currenturl + "/index.html";
currentpath += "\\index.txt";
//Add This Branch Item To The Flat List
xTreeItems.Add(xTreeItem(CurrentItem));
spaces = MakeSpace(CurrentLevel);
TocFile.WriteString(spaces);//Toc File Was Opened For Append Each
//Write To Eat Bugs
//Start A New Division
TocFile.WriteString("<UL>\n<LI>\n");
TocFile.WriteString(CurrentItem.MakeSiteMapObject());
//This Is A New Branch So Keep Spidering
InputIndexFile[CurrentLevel].Open(currentpath,
CFile::modeRead |
CFile::typeText);
HtmlOutputFile[CurrentLevel].Open(CurrentItem.LocalHtmlPath,
CFile::modeCreate |
CFile::modeWrite | CFile::typeText );
//Start A Fresh Html Page
HtmlOutputFile[CurrentLevel].WriteString("<HTML>\n<Body>\n");
//Create A Link From The Entry
HrefL[CurrentLevel] = CurrentItem.MakeHref();
//Make A Line Hrefs That Link To The Parent Level(s)
CString DirectoryBar;
DirectoryBar="";
for(int h = 1; h < CurrentLevel; h++)
{
DirectoryBar += HrefL[h] + " / ";
}
//Put The DirectoryBar On The Page
HtmlOutputFile[CurrentLevel].WriteString(DirectoryBar +
CurrentItem.Name +
"<BR><BR>\n");
//If This Is Not The Root
if(CurrentLevel > 1)
{
//Then Put A Link To This Page
//On This Item's Parent's Page
HtmlOutputFile[CurrentLevel - 1].WriteString(
CurrentItem.MakeHref() +
"<BR>\n");
}
for(;;)
{
//If We Don't Hit EOF Spider Recursively
if(InputIndexFile[CurrentLevel].ReadString(xStr))
{
xTreeItem NewTreeItem;
NewTreeItem.InitFromTxtEntry(xStr);
Spider(NewTreeItem);
}
//If We Do Hit EOF
else
{
//Close This Division
TocFile.WriteString("</UL>\n");
//Close This Input File
InputIndexFile[CurrentLevel].Close();
//This Could Be A (Nifty Page Ground)
//HtmlOutputFile[CurrentLevel].WriteString(themeFooter);
//Close The Html And Body Tags And The File
HtmlOutputFile[CurrentLevel].WriteString(
"</Body>\n</Html>\n");
HtmlOutputFile[CurrentLevel].Close();
//Decrement The CurrentLevel And Break Out Of The Loop
//So We Can Return To Whence We Came Which Was
//Probably Up There Where It Says Spider(NewTreeItem);
CurrentLevel --;
break;
//Maybe This Is Where The Recursive Action Ends Hmmm...
//All Those pMFs Pushed On The Stack Get Popped Right
//Back On To IP... OH Wait The Class This Function Used
//To Belong To Has Probably Been Removed For The Sake
//Of Simpleness So pFs If So
}
}
}
//Here Is Where The Leaf Gets Processed
else
{
//First We Need To Make Sure CurrentItem Has A URL
if(CurrentItem.Url)
{
xTreeItem LeafTreeItem;
LeafTreeItem.copy(CurrentItem);
//The Leaf Is As Far As The Spider Will Crawl
//So There's No Need To Increment The CurrentLevel
//Just Set The LeafTreeItem's Level To CurrentLevel + 1
LeafTreeItem.Level = CurrentLevel + 1;
//Ah Add The Item To The Flat List
xTreeItems.Add(xTreeItem(LeafTreeItem));
//Nothing Done With Spaces Yet Here
//Need To Standardize And Functionize The TocFile Writes
spaces = MakeSpace(CurentLevel + 1);
//Start A New Division I The Toc And Put This Item
//In As The Head Of The Division
TocFile.WriteString("<UL>\n<LI>\n");
TocFile.WriteString(LeafTreeItem.MakeSiteMapObject());
//Throw It In It's Parent's List Of Links
HtmlOutputFile[CurrentLevel].WriteString(LeafTreeItem.MakeHref() +
"<BR>\n");
//Loop Through The Rest Of The File
//Here Is Where It's Assumed That All
//Items That Follow Are Leaves
//This Is Fine For Our DirectoryTree Spider
//Where All The Links In The Deepest Folder
//Are Outside Of The Crawler's Space
//But Not For A Web Crawler
for(;;)
{
if(InputIndexFile[CurrentLevel].ReadString(xStr))
{
//Again As Above
LeafTreeItem.InitFromTxtEntry(xStr);
LeafTreeItem.Level = CurrentLevel + 1;
xTreeItems.Add(xTreeItem(LeafTreeItem));
//Those Spaces Again
spaces = MakeSpace(CurrentLevel + 1);
//We Are Allready In A Division So Just
//Make A New Entry
TocFile.WriteString("<LI>\n");
TocFile.WriteString(LeafTreeItem.MakeSiteMapObject());
//Throw It In It's Parent's List Of Links
HtmlOutputFile[CurrentLevel].WriteString(
LeafTreeItem.MakeHref() + "<BR>\n");
}
else
{
//Close The Division... We Ran Out Of File
TocFile.WriteString("</UL>\n");
//Get Out Of The Loop And Return To Next Line Of Caller
//Which Was Probably This Very Function
break;
//This Could Be Where The Recursive Action Ends
//Nah I Think It's Up There At The Branch Break
//Cause You Have To Start The Spider On A Branch
//Unless The Spider Drops From Another Tree And
//Lands On A Leaf
}
}
}
}
}
more on the spider later
http://geocities.ws/billy_stiltner/code/OSOS-3_25_am_06_06_02.zip
On Thu, Mar 30, 2017 at 9:28 AM, Christof Ressi <christof.ressi at gmx.at>
wrote:
> > If it was possible to have an array of pointers,
>
> I get your idea. You can already have [list]s of pointers but this is
> rather cumbersome. Sometimes I've wished that pointers could be fields in
> structs (don't know why that's not possible...). Together with a mechanism
> to compare pointers (right now you can only route them by their type) these
> could indeed add some new possibilities.
>
> Gesendet: Mittwoch, 29. März 2017 um 15:37 Uhr
> Von: "José de Abreu" <abreubacelar at gmail.com>
> An: "Derek Kwan" <derek.x.kwan at gmail.com>, "Christof Ressi" <
> christof.ressi at gmx.at>, pd-list at lists.iem.at
> Betreff: Re: [PD] [text define] functionality for text in structs?
> Hello, this is my first e-mail on the list, and i don't understand the
> code of pd or anything like that, but I have an idea. Plus, sorry for bad
> english.
> If it was possible to have an array of pointers, maintained by the user,
> we could jump to some scalar in the list, say I have 1000 scalars, and an
> array with pointers to 100th, 200th, 300th, or any combination. This would
> improve the search.
> Maybe this would be a list/array of pointers inside another scalar? What
> do you think?
> Using this design, the user itself can create his own structures with
> pointers, creating trees, graphs with the scalars themself.
> It make sense?
>
>
> Em Qua, 29 de mar de 2017 08:47, Derek Kwan <derek.x.kwan at gmail.com[
> mailto:derek.x.kwan at gmail.com]> escreveu:"Christof Ressi" <
> christof.ressi at gmx.at[mailto:christof.ressi at gmx.at]> writes:
>
>
> > I have - and traversing large lists of scalars by pointer can be veeeery
> slow.
> >
> yeahhhh, i figured that could be the case =P
>
> > you could hide the fact that it's a linked list from the user but I
> > don't know if that's a good thing to do. It doesn't seem transparent
> > to me ("why is accessing the 1000th elements slower than the 1st
> > element?").
>
> I suppose you could tell the user via documentation, but then you'd have
> go into what a linked list is and why linked list indexing is
> O(n) versus array O(1) to explain the speed difference and yeah,
> I see your point haha. And it's probably not good either to have a layer
> of abstraction that isn't totally necessary either.
>
> >
> > if you don't use the graphical representation, you can just as well
> > work with data structure arrays and get fast random access. there is
> > one little but unfortunate drawback compared to using lists of
> > scalars: drawn instances of array elements don't respond to mouse
> > events, making them more or less useless as UI elements. if you
> > click/select an element, you only get a pointer to the array, not to
> > the element(s). if you click on the canvas, you get pointers to the
> > array + all array elements (for whatever reason).
> > The right behaviour IMHO would be that clicking/selecting array
> > elements gives you pointers to the array *and* the clicked/selected
> > element(s). clicking on the empty canvas shouldn't trigger any mouse
> > events!
> >
> > Apart from that, data structure arrays are quite easy to handle and
> > much more efficient than linked lists of scalars
>
> ah, that's interesting. admittedly, i haven't used pd structs that much
> in my pd work as of yet but the stuff i want to do seems to be
> increasingly lending itself to that (or a similar) sort of paradigm so
> i'll keep that in mind!
>
> Derek
>
> --
> Derek Kwan
> www.derekxkwan.com[http://www.derekxkwan.com]
>
> _______________________________________________
> Pd-list at lists.iem.at[mailto:Pd-list at lists.iem.at] mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170331/f7194b38/attachment-0001.html>
More information about the Pd-list
mailing list