#foswiki 2012-01-04,Wed

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
dj_segfaultIs there a way to have the wiki editor (as opposed to the WYSIWYG or Raw editors) come up by default for a particular user? [05:24]
gac410er... wiki editor? vs. raw editor?
You can put settings like Set NOWYSIWYG = 1 in the user's topic.
set it to FINAL if you want to make sure web or topic settings can't override.
[05:25]
dj_segfaultSorry, that was way too confusing. Sorry. I meant to saw wiki editor (which is to say raw) as opposed to WYSIWYG or HTML
OK, I was getting confused by what the docs meant by raw editing. I think I understand, and see that http://foswiki.org/Support/FaqHowToMakeRawEditDefault is what I was looking for. Thanks.
[05:27]
gac410yeah Set NOWYSIWYG = 1 and Set FINALPREFERENCES = NOWYSIWYG in the user topic. [05:27]
***gac410 has left [05:36]
...................................... (idle for 3h8mn)
ChanServ sets mode: +o MichaelDaum [08:44]
MichaelDaumWikiRingBot, seen paul [08:44]
WikiRingBotWikiRingBot hasn't seen paul yet [08:44]
MichaelDaumWikiRingBot, seen pharv [08:44]
WikiRingBotWikiRingBot has last seen pharvey 3 Jan 2012 - 12:23 GMT on #foswiki [08:44]
MichaelDaummorning all
question: paul writes on http://foswiki.org/Development/SupportRelativeBracketedLinks: "... but permitting . separators [for webs] does introduce ambiguities." ....
does this only refer to Web.SubWeb.WebHome vs Web.SubWeb where the latter is a valid topic as well?
or are there any other ambiguities?
just for the records: I always disliked / as a separator for webs whereas . is used to separate the topic part in a web.topic string
using . to separate webs.subwebs from each other does work in 99.99% of all cases anyway
only exception I recently came across is RedirectPlugin ... which sort of sux
[08:45]
........... (idle for 50mn)
CDotMichaelDaum: the problem is parsing
using / for web separators clearly distinguishes what is what. For example, A/B.c is clearly a topic
and A/B is a web
that makes the web/topic decision as early as possible
[09:39]
MichaelDaumthats because you just look at the string ... not at the store [09:40]
CDotthe / separator was introduced in megatwiki as a solution to this parsing probem
because you may not have access to the store when the parse happens (context independence)
[09:40]
MichaelDaumwhere exactly do you have to know that? [09:41]
CDotI don't think you do. I'm explaining how it came about (megatwiki) where I suspect it was just laziness.
but avoiding referencing the store has (in the past) always been a good idea
[09:42]
MichaelDaumI havent seen any code in Meta.pm where this sort of problem arrises [09:42]
CDotno, cos I rewrote most of it [09:42]
MichaelDaumthe distinction whether a metaObj is a web or a topic or root isn't based on the pure path string being parsed. [09:43]
CDotif we could *enforce* A/B ratehr than A.B then it would make sense
but we can't, because A.B is already ambiguous
[09:43]
MichaelDaumwhy? [09:43]
CDotbecause context independt parsers are better
^better^easier
[09:44]
MichaelDaumthe _only_ ambiguity I can ever think of is when there was a B topic and a B subweb [09:44]
CDotcorrect - one ambiguity is enough
you may have either a web or a topic or both#
if you have a web, then there is an implicit '.WebHome'
[09:45]
MichaelDaumhuh? [09:46]
CDotA/B in a topic context refers to A/B.WebHome
more shit we inherited)
[09:46]
MichaelDaumlet's take [[Web.SubWeb]] ... does it link to Web.SubWeb.WebHome? no as far as I know. [09:46]
CDotyes, it does
try it
(I might be wrong, but I think it does)
unless SubWeb exists as a topic, in which case it takes precedence IIRC
[09:46]
MichaelDaumI tried and it doesnt link
thanks god it doesnt
[09:47]
CDotok, squabs are a bit different. i think plain Web.SubWeb will link, however [09:48]
MichaelDaumboth [[Web.SubWeb]] and [[Web/SubWeb]] dont link [09:49]
CDotCDot remembers writing a load of docco on this [09:49]
MichaelDaumeven Web.SubWeb and Web/SubWeb don't link
w/o squabs
... as expected
[09:49]
CDotI'm surprised; must have been a nightmare [09:51]
pharveyHi MichaelDaum
howdy CDot
[09:51]
MichaelDaumhi paul [09:51]
pharveymerry new year [09:51]
CDotpharvey: 新年好 [09:52]
pharveyMichaelDaum: Foswiki::Address complicates things by trying to support addressing of attachments and webs and topics (as opposed to Web.WebHome) [09:53]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Address [ (Foswiki login) PerlDoc ] [09:53]
MichaelDaumpharvey, ya I hear you :/ [09:53]
andreliHello CDot, pharvey and MichaelDaum. Happy new year - guets nöis [09:54]
pharveyso far it has worked quite well in my own testing, it even has exist-hinting to help do the right thing, and you can specify existAs => 'topic' to force the parser to produce a topic result [09:54]
MichaelDaumpharvey, kool [09:55]
pharveybut, I dunno about [[Web.Topic/attachment.pdf]] - I tried to get you guys to give me feedback, but everybody is so busy ;-) [09:55]
MichaelDaumyou most probably did not get more feedback cus this is a tough task [09:56]
pharveyit was *very* tough - but nobody liked the idea of "geeking up" the syntax [09:56]
MichaelDaumattachments have all sorts of charts in it now, including dots. [09:56]
pharveylike [[attachment:Web.Topic/attachment.pdf]] [09:56]
MichaelDaum... more dots [09:56]
andreliRegarding the topic addressing, I would like to add, that already URL to topic matching fails to identify SubWebs
Meaning: In Foswiki 1.1.3 the user gets for domain.to.wiki/bin/wiki/Web/SubWeb a topic does not exist
This is for users confusing, because they used that domain.to.wiki/bin/wiki/Web works
[09:57]
pharveyMichaelDaum: if the string is 'normal form', it can parse any attachment address confidently - the web, topic part is clearly known by the transition between separators
[[Web/SubWeb.Topic/attach.m.nt.pdf]] - I've got many unit tests for that
[09:57]
MichaelDaumyes, I see... [09:58]
pharveyif it's *not* normal form, you can still use existHints => 1 to try to guess what the user meant to target
bbiab
andreli: I agree, we need to address that problem
but... it's a constant battle between user-convenience vs deterministic behaviour
[09:58]
MichaelDaumandreli, domain/view/System works for me using trunk
can't remember this ever did not work
[10:00]
andreliMichaelDaum: yeah, but domain/view/System/Subweb (Subweb being a sub web and no topic with the name subweb exists) not! [10:02]
MichaelDaumtrue
is there any task for that?
[10:02]
andreliI just thought this issue is related to your discussion [10:04]
MichaelDaumit is
andreli, could you please file a bug report about domain/view/Web vs domain/view/Web/SubWeb ?
this is a _bug_ not a missing feature
[10:04]
andreliThere is to add, that our users struggle often as well with the href attribute in %IMAGE, which seem to have some own views on topic addressing
MichaelDaum: I will file a bug report
[10:08]
...... (idle for 27mn)
***andreli_ has left [10:35]
................... (idle for 1h30mn)
LavrUpdating to 1.1.4 at Motorola at the moment. Did not dare before because I have been away on vacation over the holidays
Going well at the moment. Still running a test parallel site
[12:05]
CDotLavr: Vacation? How dare you! ;-) [12:06]
LavrNo issues with skin this time [12:06]
CDotCDot looks to Lavr to improve the share price [12:06]
LavrHappy new year by the way :-)
Only issue I have seen so far was the disabled chili JQ plugin
[12:06]
CDotAnd a very happy new year to you too. I trust you had a good break? [12:07]
LavrIt appears the software geeks here loves it and uses it as code highlighter in all sorts of topics
I had a good break that was too short
[12:07]
MichaelDaumshould be safe to switch it on again. chili was only an issue with firefox-7. [12:08]
LavrYes. It seems like it works.
But when we replace it we need to find a way to make the chili sections still work. Some alias or something
[12:08]
MichaelDaumright. I listed some of these requirements on the related task item.
including aliasing
[12:09]
............. (idle for 1h4mn)
pharveyis foswiki.org working? [13:13]
Babar013141558 gmc [~gmc@chasmcity.sonologic.nl] has quit [Remote host closed the connection]
013141644 FoswikiBot [~bot@foswiki.org] has quit [Ping timeout: 252 seconds]
looks like not
gmc is having issues
let's tweet him
[13:19]
..... (idle for 22mn)
JulianLevensfoswiki.org is not working [13:41]
BabarJulianLevens: yeah, gmc's machine or DC is having issues
I tweeted him, but that's about him
ArthurClemens: do you have his number maybe?
or JulianLevens... the Dutch connection :)
[13:43]
MichaelDaumhm still down [13:46]
Babaryeah... not sure gmc is aware of it
tried to alert him through tweeter... didn't seem to work
if anybody has any other way to ping him... oh, I could send him an email
but that's so 1991 :)
[13:51]
CDotwith all this modern tech, there must be a way to finger him. Try asking the NSA.... [13:52]
ArthurClemensI don't have his number [13:52]
Babarok, mail sent [14:00]
....... (idle for 34mn)
MichaelDaumCDot, how about removing setArchivist and getArchivist from DBCacheContrib. Or: why does every value need a reverence to the archivist. This turns out to be a major performance bottleneck. [14:34]
CDotMichaelDaum: the idea was to allow mixing of archivists for different webs. If you are only using one everywhere, it could be a glob.
yes, I know it's one web at a time. I was trying to think of the future.
[14:35]
andreliMichaelDaum: Regarding the domain/view/System/Subweb not found bug:
There is a task filed already: http://foswiki.org/Tasks/Item9225
Even a Feature Proposal: http://foswiki.org/Development/FallBackToTopicWhenTrailingSpaceAndNoSuchSubweb
[14:36]
.... (idle for 19mn)
bertodseraHi all! FMI, is there any way to create a mediawiki style "template" in foswiki?
I mean, something I can include in pages and later expand
[14:55]
MichaelDaumbertodsera, this is done via the %INCLUDE macro in foswiki. see the docu at your System.VarINCLUDE [14:56]
bertodseraMichaelDaum: thanks, will do immediately :) [14:56]
MichaelDaumgoes like this %INCLUDE{"SomeOtherTopic" param="value" ...}% [14:56]
omg, RcsLite is _a lot_ faster than RcsWrap in a persistent perl env
mostly due to a lot of get revinfo calls to the os.
[15:07]
CDotso is NativeSearch faster than grep
for the same reason
[15:07]
MichaelDaumMichaelDaum doesnt use either grep nor its perl equiv [15:08]
CDotso you have coded it so %SEARCH works with another engine? [15:08]
foswiki_irc6hi [15:08]
CDotif not, you are using grep.
and FYI NativeSearch isn't perl, it's implemented in C
[15:08]
MichaelDaumCDot, I am not using %SEARCH at all [15:10]
CDotso you have re-implemented all the topics in System? gosh. [15:10]
MichaelDaumthe backlinks and child-topic searches are all faster using solrsearch of course
and a no-brainer to impl
as solr caches outgoug links
^outgoing
anyway
the _real_ resource hog was getRevision info via RcsWrap and tons of tons of sysmCommands
[15:11]
foswiki_irc6hello, is any body here i can ask a question? [15:13]
MichaelDaumwhy don't we default to RcsLite? [15:14]
CDotMichaelDaum: good question. I always had the impression it was because it was slower, but I have no specific evidence of that.
for a long time it didn't work very well, so was treated as a second-class citizen
[15:22]
MichaelDaumbeen profiling code using Devel::NYTProf and am knocking down the hot spots [15:22]
CDotit still has some nasty behaviours; it cracks when a topic has a lot of revs, as it tries to load the full text of every rev into memory [15:23]
MichaelDaumone hot spot was DBCacheContrib propagating the archivist property to every cached value while loading an archivist.
the other was switching to RcsLite
^was cured by switching to
these two made one page go from 7-8s down to 800-900ms
the InfiniteScroll demo for WebChanges is a lot faster now as well
had a dashboard with lots of ajaxed dashlets loading content one by one
this page was feeling like wops ... wait ... wops ... wait ... wops
it is more like flupflupflup now
[15:23]
JulianLevensI've been looking at things like TopicAddressing and DeprecateContextlessURLContructs among others. and of course some earlier discussions relating to resolving Web/Topic name conflicts. I was struck by the lack of a final resolution to one key point: being able to disambiguate in TML.
Paul's Foswiki::Address may guess correctly most of the time, but that's not user facing. Secondly as new webs come and go, the guess will change. Yes, ideally the parser should be able to know what you mean and not guess, but the syntax we have cannot always be disambiguated. So you need disambiguation syntax, but how do also make that user friendly and intuitive?
[15:31]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Address [ (Foswiki login) PerlDoc ] [15:35]
................. (idle for 1h21mn)
MassoudSCheckboxes all pre-checked in new EditTable row. Anyone knows of a solution or a trick to display them all unchecked or checked for selected few? [16:56]
***Rich_Morin has left [16:56]
bertodseraHi! question, I have links defined in an included section, only they get expanded according to the web into the included page belongs, I'd rather want them to expand relative to the page in which they are included, is there any way to force this
?
[17:07]
..... (idle for 23mn)
CDotbertodsera: links in an included page are expanded in the context of the topic they are included into. There is no way to change that.
MassoudS: yeah. Use EditRowPlugin >:-)
[17:30]
bertodseraCDot: So I must have something weird with my topics' placement. Will check that tomorrow
thanks
[17:32]
Babarok... tried to play with Arch Linux, but the more I read their wiki, the less I'm convinced. It's just a huge pile of crap made by people who know nothing about the basics of linux.
mail sent, and 5 minutes later, it was fixed :)
[17:32]
MichaelDaumCDot, which one was the "good" workflow plugin: Work
...flowPlugin or ApprovalPlugin?
[17:45]
CDotMichaelDaum: depends on who you ask.... they have slightly different functionality
both are "good" (and "bad") in their own ways
[17:45]
MichaelDaumnot that I see where they differ at first glimpse
spent the better half of today finding out that it is WorkflowPlugin's internal %cache that sux in not caching the "no-control-topic-found" during an edit of some totally unrelated topic
[17:46]
CDotthat sounds like a bug. [17:48]
MichaelDaumerm it is [17:48]
....... (idle for 33mn)
could it be that the recent changes to the template path broke UserCommentsTemplate in CommentPlugin? [18:21]
.... (idle for 18mn)
ah my fault [18:39]
............... (idle for 1h10mn)
***ChanServ sets mode: +o MichaelDaum_ [19:49]
..................... (idle for 1h42mn)
ArthurClemensphew [21:31]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)