.... At the moment it seems like I need to start over, using a data dictionary instead oftiddlers for storage.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2ef5aae4-83c9-411e-bb62-ad97832f6b2c%40googlegroups.com.
Jeremy
To unsubscribe from this group and stop receiving emails from it, send an email to tiddl...@googlegroups.com.
Perhaps if you can't share your wiki publicly perhaps you can privately to a few of us. With privacy assured.
There would be value in looking into browser memory like I suggest in a previous reply.
I find timimi is the quickest but I do use Windows 10 64bit with 16gb of ram. And since 90% of my work is in a browser now, usually in a tiddlywiki, I have lifted the ram that Firefox and chrome can make use of.
I knew of Jeremy's large wiki so thus speculated on other issues.
Can you try another computer/os or version to see how persistent the issue is.
Regards
Tony
<$edit-text tiddler="$:/temp/search/title" tag=input/>
<$list filter="[{$:/temp/search/title}minlength[3]]">
Number found: <$count filter="[tag[Vorto]prefix{$:/temp/search/title}]"/><br>
<details>
<$list filter="[tag[Vorto]prefix{$:/temp/search/title}]">
</$list>
</details>
</$list>
This version worked fine for me on a short test. Mark's original didn't.
It is a solution and a work around but the root cause is not yet known
Somehow Jeremy and others avoid this at scale as did my example but are we avoiding performance issues through techniques we have a gut instinct for but are not quantified or published?
regards
Tony
Actualy I think there may be some fundamental assumptions made in the typically sized wikis that a wrong at scale. For example the recent tiddlers list can get very large. When saving the noscript section can add a 50% to file size.Somehow Jeremy and others avoid this at scale as did my example but are we avoiding performance issues through techniques we have a gut instinct for but are not quantified or published?
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/50bc5f2c-f80c-4d2f-9485-2d1d3d22664e%40googlegroups.com.
My project may have been over ambitious. But I thought there were going to be someimprovements in 5.1.20+ that would allow for larger TW files. I currently have a TW filewith about 36,000 short dictionary definitions. Each tiddler consists only of a titleand a field, EN, with usually only 3 or four words in it. The overall size is only 10 megs.Overall, the performance is impracticably slow. Ten seconds to open a tiddler. 20 seconds or moreto do a simple search box search. As much as 25 seconds or more to close out tiddlers thatneed to render a custom search. In most cases, you have to type blind because thekeystroke refresh is also incredibly slow.I'm wondering if the performance improvements actually made it into the core, or ifmy expectations were too high. Actually, the performance noticeably declinedafter the first 12,000 entries.At the moment it seems like I need to start over, using a data dictionary instead oftiddlers for storage.Firefox, Windows 7, TW 5.1.21Thanks!Mark
<$list filter="[all[current]tag[Vorto]]">
Eng: <$edit-text field="en" tag="textarea" rows=2 class="vorto-edit" />
</$list>
Only when that tiddler is open in the sidebar, I get what Mark gets-- everything-- typing, clearing the search box, hiding/reveraling the sidebar, switching sidebar tabs has about a 5 second lag.
[...] contains:tags[Vorto] seems to work without a noticeable performance hit.
Tags should really be reserved for ad hoc unstructured labeling where it makes sense that one or more tags may be assigned. Fortunately it is easy to transfer values between tags and fields
Because tags are so versatile I am not surprised they are used less appropriately.
Before I use a tag a field etc I always ask my self about the nature of the value I am setting. I Actualy do this intuitively so it may be a job to list the conditions I use to choose.
Regards
Tony
Tags should really be reserved for ad hoc unstructured labeling where it makes sense that one or more tags may be assigned.
Because tags are so versatile I am not surprised they are used less appropriately.
Fortunately it is easy to transfer values between tags and fields
Mat
Tags should really be reserved for ad hoc unstructured labeling where it makes sense that one or more tags may be assigned.
If this is so, then TW should feature more variants of "tags" (or whatever the appropriate label would be then). For example, it is not trivial to get "myfield:Vorto" to display as a tag pill, which you might want it to.
Because tags are so versatile I am not surprised they are used less appropriately.Well, obviously Mark is an absolute TW expert so I'd say your interpretation of how tags are to be used is merely an opinion. The question is, again, if the system meets our needs.
Fortunately it is easy to transfer values between tags and fieldsThere's certainly no UI for it so it is not trivial. How do you go about it?<:-)
;Filter: <$edit-text tiddler="$:/temp/bulk/filter" tag=input/>
;Actions:
<$tiddler tiddler="$:/temp/bulk/actions">
<$transclude tiddler="$:/core/ui/EditTemplate/body/editor"/>
</$tiddler>
:`Warning - most actions may be irreversible` make backups
://consider a two step process for intermediate results//
<details open><summary>Tiddlers to be actioned - click to open/close</summary>
<$list filter={{$:/temp/bulk/filter}}>
</$list>
</details>
<$button>
<$list filter={{$:/temp/bulk/filter}}>
{{||$:/temp/bulk/actions}}
</$list>
Apply actions to selected tiddlers
</$button>
... I was thinking I would have to ditch tags, which is a shame since Thomas' beautiful list-reveal makes
it so easy to add and remove tags. But contains:tags[Vorto] seems to work without a noticeable performance hit.
Tiddlywiki allows you to do as you suggest out of the box. Just go ahead and use #tags in text. And filter on text contains or search. Perhaps a little experiment and publish this method is all that is needed. You could throw in some macros to make it easier or an editor toolbar button to insert existing hash tags. Ideally you could register new hashtags in a data tiddler so you know what you can search for or log their use.
Of course if the wiki has a lot of text or tiddler it may be wise to move such hash tags into a tag like field.
Would it be ok to use $:/#tagname because then you could have the option of creating a tiddler and using it as a tag. You could then have a view template that with [all[current]prefix[$:/#]] displaying hash tag tools when you open a $:/#tagname tiddler. References etc will also work with this.
Imagin if you could make # or /# a new namespace like $:/ is
Regards
Tony
Personally I like the freeform taggery of tools like Twitter where #hashtag is simply an in-text string to match.
Mr #Darcy, cognisant of the plebesite, announces #BottledWater should be banned.
“If I ever go looking for my heart's desire again, I won't look any further than my own back yard.Because if it isn't there, I never really lost it to begin with… "
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/c1878946-113b-49ac-b66c-6a38c6f1f29e%40googlegroups.com.
exports.getTiddlersWithTag = function(tag) {
// Try to use the indexer
var self = this,
tagIndexer = this.getIndexer("TagIndexer"),
results = tagIndexer && tagIndexer.subIndexers[3].lookup(tag);
if(!results) {
// If not available, perform a manual scan
results = this.getGlobalCache("taglist-" + tag,function() {
var tagmap = self.getTagMap();
return self.sortByList(tagmap[tag],tag);
});
}
return results;
};
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/160dda32-67cc-4078-b76a-3e2408239d99%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddl...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddl...@googlegroups.com.
but just as tiddlywiki already has the type field for its own tiddler types the best way for a designer to handle the example of classifying a large number of tiddlers as words/Vorto is with a field be it containing a tiddler-type value or just an if exist "word" field. Why because it does not use a heavily flexible mechanism for tags to do a simpler job, and in large quantities this makes a difference.
Personal or vanity tree
The personal or vanity tree includes media types associated with non publicly available products or experimental media types. It uses the
prs.
tree prefix:
type "/" "prs." subtype ["+" suffix] *[";" parameter]
Examples:
audio/prs.sid
,image/prs.btif
.
from Wikipedia