#foswiki 2017-03-24,Fri

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

WhoWhatWhen
vrurgActually, a key could also be referenced with {Key}{SubKey} format but more like a respect to the legacy format.
I was thinking similar way. Plus it somewhat preserves the legacy styling.
[00:00]
gac410y. For existing devs, its a comfortable reference. It's not really used a lot, but there are a few places, mostly with respect to the data directory. [00:01]
vrurgThough someone could use it like ${{Key}{SubKey}} which looks ugly (this is the only why I was thinking about %) – but I doubt it'd be popular.
Ok, thanks!
[00:01]
gac410I can't think of why the "dot" separator wouldnt be useful. It's a lot less typing. ;) [00:02]
vrurgI would try to consider support for ${Key}{SubKey} form – to simplify parsing of the legacy format where it would be sufficient for the parser to just remove Foswiki::cfg and do no more job. [00:03]
gac410that sounds reasonable. [00:03]
vrurgI already use it in error messages – this is often the way people learn new stuff. ;) [00:03]
gac410tbh though, why not just go with ${key}{subkey} and don't introduce the new format. This really is not all that widely used. [00:04]
vrurgBecause this is about the internals. The parser already supports both {}{} and dot form – so, it wouldn't matter to the end user which one to use.
But to other API calls dot notation might save some time for both developers and the core (though the latter is pretty minor saving)
[00:05]
gac410Well except for configure, the referenced key should already be replaced. Running wiki should never see that embeded config reference I don't think.
The only place the un-expanded string is used is when presenting it to the user in the Config UI
[00:07]
vrurgIt's not only about embedding.
The Config object has now get and set methods which both support the format. So, generally I would like get away from using the hash directly but rather to have it like $cfg->get("Key.SubKey");
Another application is storing the config in a database where the key column would containt the dot notation and the whole thingy would be as simple as plain two-column table.
[00:08]
gac410Isn't that going to slow things down. The config hash is really heavily used internally, sometimes in loops. Making every reference a subroutine call has got to be expensive. [00:10]
vrurgWhy not to fetch it once in a variable and re-use then? With Moo or any other OO framework this should be (and it is for me) a common practive to cache values because attributes are sub calls. [00:12]
gac410Of course it's simple enought to $cfg->get() outside of loops, but it will sure take a lot of tuning / refactoring [00:12]
vrurgIn this model the hash is stored in data attribute and is used like $cfg->data->{Key}{SubKey} – which is eventually no much faster that calling get() method.
I think tuning will be necessary anyway. But so far psgi+nginx is giving quite significant boost which could let this job to be postponed for a while.
[00:13]
gac410anyway, I think the "$..." format aka a string token sounds better than a %... macro style. And for sure I'm sure nytprof will get run eventually ;) [00:15]
vrurgPlus I was trying to do the job of pre-fetching config values wherever possible already.
BTW, when I'm making a big enough pause in development and occasionally re-run nytprof I get shoked for a while until recall the source of issue. My code is EXTREMELY slow in DEBUG mode. Most of the slowness comes from object creation and I get shoked every time when see the results – until recognize that the base class records stack to allow finding out the exact location where an object was created and how the code came to this locati
(already helped to fix a number of memory leaks). But Carp::longmess which is used for this is DAMN SLOW and takes perhaps more than 50% of CPU time.
[00:16]
gac410wow.
That will be a good thing to point out
[00:20]
vrurgRecently added support for FOSWIKI_NOSTACKTRACE variable to switch the feature off.
Ok, back to expanding the values. If everything goes well I would let myself cut off the old readConfig code and switch over the new specs.
[00:21]
gac410cool [00:22]
vrurgAh, that's not all news. Do you remember the discussion around caching? I checked out the CHI module. Turns out it's not that helpful as I expected. It is great for timed caching. But when a cached object could last as long as possible – like until a file gets updated – then there is no direct support for this kind of situation. [00:25]
gac410too bad. Having a common caching approach would be nice. [00:26]
vrurgThough there is a workaround with storing a semi-permament object and manual expiring which could be done in a wrapper/inheriting class. I don't really like it but have to admit: there no modules better than CHI. [00:27]
gac410Well, if it fits well in some places and others really are not a fit, then having two approaches is probably better than trying to shoehorn both into a single implementation. [00:28]
vrurgWe'll have some more discussion on this when the dust around 3.0 settles down (and there will be a lot of it, I'm totally positive!).
We'll see. Another approach would be to get in touch with Jonathan Swartz and try to convince him to extend the functionality.
Ok, that was just to share some more info.
[00:28]
............................................................................. (idle for 6h22mn)
***ChanServ sets mode: +o cdot [06:52]
..... (idle for 23mn)
ChanServ sets mode: +o MichaelDaum [07:15]
........................... (idle for 2h11mn)
MichaelDaumcdot, theme modern is missing, yet it still works on trunk.f.o [09:26]
cdotmising from what? [09:26]
MichaelDaumon my disk ... git sux
it clearly differs from https://github.com/foswiki/distro/tree/master/TinyMCEPlugin/pub/System/TinyMCEPlugin/tinymce/js/tinymce/themes
[09:27]
maybe updateing TinyMCEPlugin's gitignore would help to weed out some leftovers ...
puh this is uggly
cdot, how do I switch off the bottom status bar, the one with the "p .... words \d\d\" in it
[09:39]
cdotMichaelDaum: I assume it's done in the init sequence. What you are seeing it pretty much vanilla TinyMCE.
ah, the words thing is the wordcount plugin, I think
[09:46]
MichaelDaumgot that switched off yes, but what about the dom indicator? [09:47]
cdotI didn't spend any time playing with the 4.5.3 config, so your guess is as good as mine :-( [09:47]
MichaelDaumall of the bottom gray bar
and the resize widget
[09:47]
cdotcrap... did I remember to commit the NatEditPlugin changes? :-/
n.m. I must have, otherwise it wouldn't work
[09:49]
MichaelDaumstatusbar: false [09:52]
GithubBot[DatabaseContrib] cdot pushed 1 new commit to master: https://git.io/vSUus
DatabaseContrib/master 0d23e2f cdot: Item14348: fixed over-restrictive access controls. Rewrote big chunks of the doc to reflect what I discovered while trying to use the contrib.
[09:55]
***GithubBot has left [09:55]
FoswikiBothttps://foswiki.org/Tasks/Item14348 [ Item14348: The allow_* method of access control is a complete pain in the ass. ] [09:55]
....... (idle for 33mn)
GithubBot[distro] MichaelDaum pushed 2 new commits to Item14288: https://git.io/vSU2n
distro/Item14288 2cc13e1 MichaelDaum: Item14288: Merge branch 'master' into Item14288
distro/Item14288 b1d18e0 MichaelDaum: Item14288: cleanups...
[10:28]
***GithubBot has left [10:28]
FoswikiBothttps://foswiki.org/Tasks/Item14288 [ Item14288: rewrite to support pluggable edit engines ] [10:28]
MichaelDaumcdot, https://github.com/foswiki/distro/commit/b1d18e0f8ea0dae13f5c4d84789d420784f7d8e2#diff-3b3c5bd563e0b6a14a4f6293d694510f [10:38]
tinymce.activeEditor.plugins.foswiki.image_list
error when inserting an image
or in image context menu
[10:46]
cdotok, cool, but why did you cut all those files out of the tinymce distribution? [10:47]
MichaelDaumfoswiki_tiny.js:80
I merged from master into the item branch
at least I tried to
[10:47]
cdotduh, sorry, it's just gitignore [10:47]
MichaelDaumoh ah yea [10:48]
cdoterror when inserting an image? what sort of error? [10:48]
MichaelDaumUncaught TypeError: tinymce.activeEditor.plugins.foswiki.image_list is not a function
as foswikiiamge is gone I assume this is a left-over / tbd
away for lunch ... more later
[10:49]
cdothmmm, maybe [10:59]
.... (idle for 19mn)
GithubBot[distro] cdot pushed 1 new commit to master: https://git.io/vSUiI
distro/master 0d5df86 cdot: Item14323: missing {} causes mayhem
[11:18]
***GithubBot has left [11:18]
cdotwas a typo, fixed [11:18]
FoswikiBothttps://foswiki.org/Tasks/Item14323 [ Item14323: Update to latest TinyMCE version ] [11:18]
.......... (idle for 45mn)
***ChanServ sets mode: +o MichaelDaum [12:03]
GithubBot[distro] MichaelDaum pushed 1 new commit to Item14288: https://git.io/vSUMx
distro/Item14288 419c2f5 MichaelDaum: Merge branch 'master' into Item14288
[12:07]
***GithubBot has left [12:07]
FoswikiBothttps://foswiki.org/Tasks/Item14288 [ Item14288: rewrite to support pluggable edit engines ] [12:07]
............. (idle for 1h4mn)
***ChanServ sets mode: +o Lynnwood [13:11]
GithubBot[distro] MichaelDaum pushed 1 new commit to Item14288: https://git.io/vSUNv
distro/Item14288 cea4f5c MichaelDaum: Item14288: moved all tinymce specifics...
[13:24]
***GithubBot has left [13:24]
FoswikiBothttps://foswiki.org/Tasks/Item14288 [ Item14288: rewrite to support pluggable edit engines ] [13:24]
...... (idle for 28mn)
GithubBot[distro] MichaelDaum pushed 1 new commit to Item14288: https://git.io/vSUpM
distro/Item14288 afc509a MichaelDaum: Item14288: jslint'ing some
[13:52]
***GithubBot has left [13:52]
ChanServ sets mode: +o gac410 [14:04]
.... (idle for 18mn)
gac410MichaelDaum: cdot ... could you review my comments to Item12090. I thing that this is really a documentation error. There is a conflict in the documented features. [14:22]
FoswikiBothttps://foswiki.org/Tasks/Item12090 [ Item12090: Field name -with description- in Forms not working properly ] [14:22]
gac410I cannot see how in a field definition, Both [[Fieldname][Field description]] and [[TopicName][Field Name]] can both be true. Either the left side is the field name, or it's a topic name [14:25]
cdotgac410: you are right. [14:25]
gac410phew. I was wondering if someone implmented a "Do what I mean, not what I wrote" module/feature.
Okay ... I think I can fix this one ;) Deleting documentation is easy enough for me.
[14:26]
cdotthe second sentence isn't wrong, it's just very misleading [14:30]
gac410Okay. Well I'll try to reword it all so that it makes sense and point out the prior issue. When using a squab as the field name, the left side always references a topic name, and the right side is always used (with transformation) as the field name.
Probably a good point to reference the Pre 2.x transformation rules (elimination of non-a-z...) and backwards compatibility configuration as well.
[14:32]
MichaelDaumas well as the legacy switch to bring the old transformation rules back again [14:39]
gac410yes, that's what I meant by "backwards compatibility configuration" .. ;) [14:39]
...... (idle for 25mn)
MichaelDaumcdot, how do I insert a table header in tinymce? [15:04]
cdotisn't there a context menu for that? Right mouse button? [15:07]
MichaelDaumyes but it doesnt seem to work on trunk.f.o
it does so on tinymce.com's demos
[15:07]
cdotdoes it seem to work in the editor, and then not save?
MichaelDaum: maybe it's a plugin that we're missing?
[15:08]
MichaelDaumthe table plugin should be doing the trick doesnt it [15:10]
cdotTMCE appears to move the row into the THEAD, but it leaves it as a TD, doesn't make it a TH [15:12]
MichaelDauminspecting the iframe dom it does indeed insert a thead tr th fragment. however switching to wiki editor it doesn't translate properly. I think this is related to your recent bold-content change.
ah right
[15:12]
cdotno, it's because the "heading-ness" is detected by it being a TH. A TD in a THEAD isn't detected as a header :-( [15:13]
MichaelDaumsnap [15:13]
cdotRaise a report against WysiwygPlugin. I might fix it some time next decade.
Or gac410 might fix it. He's a WysiwygPlugin guru, now.
[15:13]
gac410ha..
raise a task and I'll try to take a look later today .. .off to pt again
But do NOT read into that ... that I'm acknowledging being a wysiwyg guru. Whenever I touch the code I seem to find another rat-hole and get punished for attempted good deeds.
The only thing that makes touching wysiwyg even remotely possible is it's very thorough test cases.
[15:15]
MichaelDaumhere you go https://foswiki.org/Tasks/Item14353 [15:27]
..................... (idle for 1h43mn)
gac410cdot: Two unit tests are failing TranslatorTests::testTML2HTML_stickyInsideLiteral and TranslatorTests::testTML2HTML_verbatimInsideLiteralItem1980 [17:10]
FoswikiBothttps://foswiki.org/Tasks/Item1980 [ Item1980: Sticky tags within Verbatim Tags results in data loss ] [17:10]
gac410It appears that it's just formatting? The returned error uses <strong>message instead of *message
I'm assuming that in this case, it's okay to just change the test?
[17:10]
GithubBot[distro] MichaelDaum pushed 1 new commit to Item14288: https://git.io/vSTgX
distro/Item14288 8586ff9 MichaelDaum: Item14288: fixed submit process
[17:13]
***GithubBot has left [17:13]
FoswikiBothttps://foswiki.org/Tasks/Item14288 [ Item14288: rewrite to support pluggable edit engines ] [17:13]
.... (idle for 19mn)
cdotgac410: hmmm I though I fixed all the unit tests. I remember poking stickyInsideLiteral [17:32]
gac410It;s not the sticky inside literal that's different, it's the message saying that wysiwyg is disabled
-  *Conversion to HTML for WYSIWYG editing is disabled because of the topic content.*
+ <strong> Conversion to HTML for WYSIWYG editing is disabled because of the topic content.
[17:33]
cdothuh - don't think I touched that [17:35]
gac410I noticed it failed in florian's nightly tests as well
And just to be all around annoying ... I don't think Item14353 is a bug. It's workiing as designed. :P
[17:36]
FoswikiBothttps://foswiki.org/Tasks/Item14353 [ Item14353: a td in a thead is not translated into a table header ] [17:37]
gac410If you highlight a row, right-clikc, edit cell properties, and make them header cells, it works fine. [17:38]
cdotdoes it? OK. Good :-)
cdot was just about to look at that
[17:38]
gac410if you hightlight a row, and make the row a "header row" but leave all the cells as data cells, you don't get header cells.
I guess it could be argued that if you make a row a header row, then all the cells within ought to be header cells, but I'm not convinced :D
[17:38]
cdott's a point though. What is a "header"? Is it a row inside a THEAD, or is it a TH? HTML is typically vague. [17:39]
gac410y. TML doesn't really have any way to mark an entire row as a header. It's purely a cell by cell determination. [17:40]
cdotsure. And THEAD is just a nottational convenience https://www.w3.org/TR/html5/tabular-data.html#the-thead-element (note the broken example)
also there is no "TCOL" concept in HTML (how would that work?) . THEAD really is nasty, and probably should be avoided.
[17:42]
gac410right. If it was *possible* it might be nice to suppress the option to set any row-level attributes in the editor. Since we can't really support them. [17:44]
cdotin roundtrip terms, if <thead><tr><td>Fred</td></tr></thead> were mapped to | *Fred* | there would be no way to get back to the HTML, as | *Fred* | is <tr><th>Fred</th></tr> [17:44]
gac410y [17:45]
cdotI don't think it's possible. TMCE layers on top of the in-browser editing functions, and it is those that handle this sort of thing. [17:45]
gac410So we can really define how we handle thead any way we want. Right now from what I can tell, it's ignored. It's not mentioned anywhere in the roundtrip tests [17:46]
cdotthat's because the Render code never generates THEAD. It's meaningless in a TML context. [17:47]
gac410right. btw the example you pointed out is not broken. "A thead element's end tag may be omitted if the thead element is immediately followed by a tbody or tfoot element." [17:48]
cdotI *think* THEAD is intended for grouping headers when - for example - you have frozen head rows in a large scrollable table
y, I know it self closes, but it's bad XML and should be discouraged IMHO/
[17:48]
gac410Well we *could* when we detect a thead, auto-bold all of the cells within the block, I suppose. I'm not convinced that that's right, though. [17:51]
cdotme neither. [17:52]
gac410As I try to describe this to michael, maybe it's not so bad. *if* you set the row to a header row, then all cells are bold. If you want to pick/choose the cells, then just set individual cell attributes.
Since the row-level thead will be discarded in the tml, it is just a bit more friendly to let the user set this as a row-leve attribute. Of course, I have no idea how complex that change is to the dreaded HTML2TML processor.
So thead never makes the roundtrip. If set, all cells become th. On next round trip, they are just th cells, with no thead. So we still discard the row-level concept.
[18:01]
cdotthe problem I have with that is that the WysiwygPlugin is *not* specific to TMCE. It has to take a broad view of possible HTML sources. Now, the TMCE model for defining a header row doesn't make any statement about the expectations for formatting the cells in that row - which is correct, it shouldn't. But imagine another HTML source that does this: <thead><tr><th>HEAD</th></tr><tr><td>not head; sticky data only</td></tr></thead>
The TH is an unequivocal statement "this cell is a header cell" and therefore maps 1:1 to | *Head* |. But the THEAD might be being used for an entirely different purpose, unrelated to presentation. To try to draw an implication from it's use is like assuming the presence of birds because you have found eggs.
[18:09]
gac410Well the TMCE can do that as well. set the row as a header row, and then set a subset of the cells as header cells. [18:11]
cdoty, we really need to take a closer look at TMCE some time and switch off legacyoutput. But as I noted somewhere else, that implies having to integrate a CSS parser with WysiwygPlugin, and that scares me. [18:12]
gac410So we document that settining a row to a header row has no equivalent in tml, and will be discarded. [18:12]
cdotyes. WYSIWYG. And if you don't *see* it, you don't *get* it. :-) [18:12]
gac410true
btw, that <strong> vs * on the warning message. The module that sets that message has not changed since Dec. 2015. (lib/Foswiki/Plugins/WysiwygPlugin/Handlers.pm)
So I have no idea why it's now failing. I tried adding some white space, but it still generates <strong> and not *msg*
[18:13]
cdotmaybe something in the test code? [18:17]
gac410BTW cdot, I inserted two tables, and had no way to position the cursor between them. Not sure if that's our bug or tmce. [18:17]
cdotTMCE
you can try reporting it upstream. But it's a bit like trying to signal a passing airliner with an air horn.
[18:17]
gac410y they are not terribly responsive are they.
okay .. indeed you are correct. There is "nothing to see" when you set a row to a header row. ... so the answer is " .. move along"
Well, I've answered Michael in the task, saying as you suggested, When you set a header row, there is nothing to WYSee... so there's nothing to get :D
[18:20]
........................ (idle for 1h55mn)
rick_soc1hello [20:19]
gac410hello [20:19]
rick_soc1I'd like to get foswiki running on an existing lighttpd instance, existing domain, without vhost [20:21]
gac410hm I know very little about lighttpd [20:22]
rick_soc1The few pages on the foswiki site that cover lighttpd are a few years outdated, and make some assumptions that don't apply to my setup
I can probably figure it out myself but just need to know where to start
If I run the lighttpd.pl for testing, works fine
[20:22]
gac410yeah. We very seldom ever see lightppd. Mostly apache, and nginx is gaining in popularity . [20:23]
***ChanServ sets mode: +o Lynnwood [20:24]
gac410My guess would be you'd want a directory to house all of foswiki and also a prefix in the url path. ie yoursite.com/foswiki/ at the front of any paths - pub, bin, etc. [20:24]
rick_soc1Right.
I just need to know which directories should be public, and which shouldn't
And how to properly support fastcgi
[20:26]
gac410the only directory directly accessible is the pub directory. And bin - for the executables. You would never expose any other directory for direct access. [20:27]
rick_soc1okay so if I move pub and bin to a public path
what do I need to change so everything else is accessible to those files
is this what LocalLib.cfg is for
[20:32]
gac410I've never tried moving just those directories. Typically foswiki/pub and foswiki/bin are accessible, and foswiki/everthingelse is blocked.
No LocalLib.cfg is used to override the perl libpath. Typically not needed.
foswiki bootstrap is going to assume that all the directories are in the same place. If you really want to split them apart, then the configuration can indeed specify separate paths for each directory. But bootstrap would not be able to figure it out. Thats all manual configuration.
[20:34]
rick_soc1It seems really risky to keep a bunch of paths that shouldn't be accessible within the same public accessible root path [20:38]
gac410Foswiki is laid out to "unzip and go" from a common directory, and provides apache configs necessary to protect the stuff that should be protected. It's been that way for almost 20 years.
It certainly is possible to move stuff around, but upgrades will be painful.
[20:41]
rick_soc1I'm running the lighttpd.pl and grabbing the /working/tmp/lighttpd.conf it generates =) [20:43]
gac410I'd recommend getting it all running from one common directory. Then look at bin/configure in the File System Paths tab. You can copy directories out to another location (from the shell), and then change the paths in bin/configure to point to the new locations. [20:44]
rick_soc1ah ok [20:46]
gac410ie. ScriptDir and PubDir stay put, but you can relocate {DataDir}, {ToolsDir} ... and so on. [20:46]
rick_soc1Perfect, that puts me where I need to be to get this working
thanks much
[20:46]
gac410We don't test with that type of relocated configuration. It *should* work. Extensions installer should re-map all the relocated directories, But you are a pioneer here. So expect some arrows.
ugh. the lib directory may be a problem.
You indeed might need to fiddle with bin/LocalLib.cfg. As we don't have a setting for that, I'm not sure how well the extensionsn installer will figure it out
[20:47]
rick_soc1Ah this is what I needed to get this to work. Grabbed it from the tmp lighttpd.conf that gets created: $HTTP["url"] =~ "^/bin" { cgi.assign = ( "" => "/usr/bin/perl" ) }
This is what I get for going with the least popular web server option
[20:49]
gac410All the scripts attempt to locate the lib directory based off of the bin directory. No setting because catch-22. need to have a lib to even get the settings applied.
Well even with the other web servers, you'd have similar issues relocating directories.
[20:51]
rick_soc1I mean for getting it running, I'm still at that step [20:57]
..... (idle for 20mn)
gac410I did just get lighttpd running using the tools/lighttpd.pl script. used -p 8081 -s /usr/sbin/lighttpd -f and it's up with fastcgi
There is one bug, seems to be a lighttpd issue as I recall. After login, it redirects to localhost:8081/?validation=.... And as I recall lighttpd doesn't like query parameters with an empty path.
Took me a while. lighttpd has an undocumented dependency on gamin (fam) and ubuntu didn't install it automatically
[21:17]
.... (idle for 18mn)
GithubBot[distro] gac410 pushed 1 new commit to Release02x01: https://git.io/vSkmz
distro/Release02x01 83dcbc6 George Clark: Item12090: Clarify documentation of dataform field names
[21:37]
***GithubBot has left [21:37]
FoswikiBothttps://foswiki.org/Tasks/Item12090 [ Item12090: Field name -with description- in Forms not working properly ] [21:37]
GithubBot[distro] gac410 pushed 1 new commit to master: https://git.io/vSkmS
distro/master 5b45b80 George Clark: Item12090: Merge branch 'Release02x01'
[21:39]
***GithubBot has left [21:39]
....... (idle for 31mn)
rick_soc1stuck. :/
Looks like I got the FastCGI working
But accessing the bin files throws a 500 with no other useful output in the error log.
[22:10]
gac410hm Do you have all the dependencies installed? Try running tools/dependencies ... That will show if any perl modules are missing. [22:11]
rick_soc1Ah ok [22:12]
thx [22:19]
............... (idle for 1h11mn)
GithubBot[DatabaseContrib] vrurg deleted Item14348 at 0b09b11: https://git.io/vSk8p [23:30]
***GithubBot has left [23:30]
FoswikiBothttps://foswiki.org/Tasks/Item14348 [ Item14348: The allow_* method of access control is a complete pain in the ass. ] [23:30]
..... (idle for 24mn)
GithubBot[DatabaseContrib] vrurg created Item14348 from master (+0 new commits): https://git.io/vSedK [23:54]
***GithubBot has left [23:54]

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