Results 1 – 5 of about 7700.
|
Search took 0.01 CPU seconds.
|
|
| |
In lugnet.admin.general, Dan Jezek writes:
> > [...]
> > example, to limit posts to the last 10 days, use
> >
> > &qs=864000
>
> It works great! ... but the &qs doesn't carry over to the next page of
> results. So if I want to see more pages, I have to edit the querystring on
> each page.
oops, doy! I didn't put in the propagation of that URL term. I don't consider
it 100% "documented" yet (it's still subject to change without notice), but I
still shouldn't have missed that. Thanks. I'll fix that.
The reason it's subject to change is partially because the letter 's' in 'qs'
is named after the word (or greek letter, rather) 'sigma' -- sigma being 1
standard deviation in the bell curve function f(x) = exp(-x^2/2) -- and that
formula isn't being used anymore in the searches, and partially because 'qs'
might better someday be used for "query subject." Anyway, it's still not 100%
in stone. But it'll work until it breaks.
> Since you already have the inner workings of this in place, it
> would be really easy to just add a textbox named "qs" and add the &qs= to
> the bottom "5 more, 10 more"... links. With a little more effort, you could
> include radio buttons to have the user select how many days, months or years
> they want to go back and have your search engine convert it to milliseconds
> depending on what the user selects.
Yup, that's the idea!!! Say, where is that old article about sigma and
advanced options...ah! so easy to find now! :-)
http://news.lugnet.com/?q=url+query+qs+qt+sigma+%3C//1.5
(See topmost result and related thread for more background.)
> > It's actually in the nature of search engines to generate thousands of
> > results.
>
> If given thousands of results, most search engines have some advanced
> options like sorting.
Well, they -are- sorted. They're always sorted -- always highest probability
of relevance first, lowest last. Usually, the metric for relevance is a
combination of non-temporal factors such as word frequencies, word proximities,
and word orderings. I don't know of any search engine that doesn't sort (on
some criteria) the matches it finds. But anyway, I think you meant sorting
by time?
I wonder if a little link at the top to re-deploy the search taking recentness
into account (or conversely, turning it off if it's on) would be useful?
> > What's more important is the first page returned -- i.e., the ranking.
> > Typically one doesn't dig down past the first few, so you rarely
> > actually go visit all the thousands.
>
> I'd be interested in seeing some statistics on how far the average user goes
> when given back let's say 10, 100 and 1,000 pages of results. It would help
> in the design of an effective search engine.
Me too. I'd expect a f(x)=1/x type of curve, but it would be fun to see actual
numbers. :-)
--Todd
|
|
|
| 
url, query, qs, qt, sigma
(score: 13.156)
|
|
| |
In lugnet.admin.general, "Robert Munafo" <munafo@gcctechNO.SPAMcom> writes:
> In lugnet.admin.general, Jeremy Sproat writes:
> > [...] I haven't been able to figure out how to use it; e.g., what is
> > the syntax to, say, modify the query to prefer articles from about four
> > months ago?
>
> It appears that for now we just have the recent (default) target time and
> 1-week sigma values. If there is a syntax for overriding these, Todd hasn't
> chosen to tell us about it. I would guess that it isn't yet ready for general
> use.
A syntax vis-à-vis URLs isn't yet defined, but how does this sound?--
There's currently q= for the query string:
http://www.lugnet.com/?q=jeremy+sproat
and qn= for subsequent pages of results:
http://www.lugnet.com/?q=jeremy+sproat&qn=60
so there are still 25 possibilities in the q*= namespace. How about qt= for
the target time and qs= for the sigma (provided that some other non-greek
mnemonic can be identified for 's'):
http://www.lugnet.com/?q=jeremy+sproat&qt=-10519200&qs=2629800
4 months is about 10519200 seconds, and 1 month is about 2629800 seconds, so
that query would mean "prefer articles from about four months ago, with a
preferential spread of about a week or two either way."
For clipping absolute time ranges, how do qt0= and qt1= sound?--
http://www.lugnet.com/?q=jeremy+sproat&qt0=-1814400&qt1=-0
with the sign of qt0-qt1 specifying the sort order, chronological or reverse
chronological.
As far as the numerical values themselves go, they could absolute times in
the standard epoch format (seconds since 1 Jan 1970 00:00:00 GMT) or
relative times or both, or expressed in hours or days instead of seconds.
I'd favor seconds and standard epoch time, with a transparent query
generator page. That is, say the advanced search page is at /news/search/,
and you specify "about 4 months ago." Then it should calculate the current
time minus 10519200 seconds for you automatically, and do a double-CGI call:
first to process the form and convert "4 months" into 10519200 and second to
respond to the query itself. (I wouldn't want to litter the URL line with
all of the possible options present on the actual human-interface form
because it's important to keep the URLs short and to separate (abstract) the
query interface layers.)
So when you click the Go button on the advanced search page, it would do
that via HTTP POST (not GET), and that script would interpret the query, and
rewrite it into a URL which gets spit out via a Location: header to enact
the actual query. (It would be 99% transparent -- all you'd actually see in
your browser is "contacting host..." twice in rapid succession.)
In the URL parser, positive values for time could be interpreted as absolute
values and negative values for time could be interpreted as relative values
(relative to the current time).
--Todd
|
|
|
| 
url, query, qs, qt, sigma
(score: 9.012)
|
|
| |
In lugnet.admin.general, Dan Jezek writes:
> Wow! So you have terms for the ampersand options in a URL? My standpoint
> on this would be to put everything in a form and kill 2 birds with 1 stone -
> not having to think of how to name URL terms (unless you enjoy doing that)
> and having the search more user-friendly (not everyone will remember the
> options or find it easy to edit the URL).
Ya, exactly -- first name the URL components carefully and then put a user-
friendly level on top of it. Best of both worlds.
> No, I meant having the option to pick between what I want the results to be
> sorting on. Dejanews has a great power search:
>
> http://www.deja.com/home_ps.shtml
>
> which includes the option to sort by relevance, subject, forum, author and
> date. That's how I would like to see the sort options here.
Ah, I see. Yeah, that could be helpful in certain cases, if you're scouring
tons of results! I've needed to look things up on Deja.com, so I know what
you mean.
> But knowing
> that you most likely don't have the resources that dejanews has and how
> flawlessly Lugnet runs on the current setup, I'm satisfied with editing the
> URL for now :-)
There's an alternate form that avois the &qs= thingie, so you don't have to
edit the URLs:
http://news.lugnet.com/admin/general/?n=8613
> It could be done. Include another version of jump.cgi into the 5 more, 10
> more... on the search results page and log the number of results returned,
> the IP address and the query subject.
These don't actually run through jump.cgi. But they're already logged by
httpd anyway. (That's how the jump.cgi logging is implemented as well.)
> Then run an average, min, max query
> grouped by all 3 fields. Sounds complicated, depends on how badly you want
> to see the results. I wouldn't want to go through the process of
> implementing that but would really like to see the results :-)
Hmm, it's all there now, except for logging the number of results produced.
I guess it could be as simple as open for append, flock, print, and close on
a filehandle inside of the search page...lemme think about it. Analyzing the
results and making a graph would be a snap with gnuplot.
I think it would be especially fun to compare the graph now to the way it was
(would have been) before the change...but alas, that data was never captured
for the old query engine and it's too late now.
--Todd
|
|
|
|
url, query, qs
(score: 5.039)
|
|
| |
In lugnet.cad, Kevin L. Clague wrote:
| |
The problem here is that the PDF library limits things to specific page
sizes, *and* those page sizes are in centimeters, not inches. When you
specify a size LPub finds the closest page size from this list
http://doc.qt.nokia.com/4.5/qprinter.html#PaperSize-enum
that wholly encloses the page size you specified.
8.5x11 is a little smaller than its metric counterpart.
|
It’s true that 8.5”x11” (US letter size) is not the same size as metric A4, but
the above page includes an entry for QPrinter::Letter, which is exactly
8.5”x11”, so unless that’s not supported by LPub, I don’t think that’s the
problem. Remember, one inch is exactly 25.4 mm, so 8.5 inches is exactly 215.9
mm. So the fact that Qt internally use metric units shouldn’t hurt anything, as
long as those metric units can at least resolve one tenth of a millimeter.
--Travis
|
|
|
|
qs, qt
(score: 3.961)
|
|
| |
In lugnet.cad, Mike Walsh wrote:
| |
In lugnet.cad, Kevin L. Clague wrote:
| |
In lugnet.cad, Mike Walsh wrote:
|
... snipped ...
| |
Things seem fine through page 14, and then they go away. One of two things
come to mind. Either it is an LPub bug, or, possibly the page number is
hiding *under* the PLI? I’d make sure that the PLI is placed relative to
the page number.
You can always send me your MPD (which will be held in the strictest of
confidence), and I can look at it.
|
I’ve moved the PLI around thinking it was underneath it but it didn’t seem to
make a difference. I will send you the MPD file so you can take a look at
it.
|
I found a bug in LPub.
| |
| |
| |
- The other issue I am dealing with is scaling - my Airport Shuttle is long - about 200 studs when it is all put together. This makes it hard to fit on a page. When I scale the final assembly all of the other step images scale too. I can’t seem to scale the image for just one step. Any ideas?
|
Go to the final page, put your cursor on the assembly step and right click.
You should be able to set the model scale just for that step.
|
I tried it but even though I told it to apply to only this step, the scale
was applied to the entire set of instructions. I will try it again and see
if I can get it to work.
|
Yes, your highest level model is interesting because the entire model is
expressed as steps in submodels, so when it placed the model scale meta, it did
it at the top of the step (which is before all the add lines of the submodels).
I moved the meta manually to after all the submodels, and it worked. Sorry you
have to do that manually, it is hard to figure out a usage model for placing
meta commands that fits *all* possible cases.
| |
| |
| |
Any other suggestions are welcome.
|
Given that your overall model is more wide than tall, had you considered
using a more landscape set of page dimensions? Go to page configuration and
swap the numbers in page dimensions to get landscape.
|
I tried both landscape and portrait orientations and settled on portrait as
it seemed to fit the majority of the pages better.
Enhancement request: Allow per page size overrides! ;-)
|
Egads.... makes my brain hurt with regards to printing.
| |
| |
Did you know that you can resize PLI’s by dragging the mouse? It would seem
you might be able to merge page 11 and 12 if you shorten the PLI in step
7....
|
I didn’t know that - I will give that a shot. I have a couple places where I
ended up with only one step on a page when it would make the instructions
flow better if there were two.
|
Using placement features new to LPub 4 (placing callouts relative to step
group), I was able to eliminate about 1/3 of your pages.
Also, LPub 4 tries to size the PLIs in step groups based on the size of the
assembly step automatically if you do not have metas that specify PLI
constraints. I removed a bunch of your PLI constraints (using the edit window),
and this helped things pack more densely.
| |
| |
| |
Last question - is there a way to generate a complete BOM image for all of
the parts needed to build the model and add a BOM page at the end?
|
Add a trailing cover page, then you should be able to use the “Insert BOM”
menu.
|
Ok - got that working, thanks. The Insert BOM menu was greyed out until I
added the back cover page, just adding a page wasn’t sufficient.
|
Hmmm.... I will dig into this. BOM should not be limited to back cover page
(i.e. it should be placable on front cover page). It is not placable on pages
with steps.
| |
| |
Thanks for the nice comments about LPub on your web page. Did you know that
you can create a cover page and insert a picture into the cover page? You
should not *have* to use Acrobat for that.
|
I tried to create a cover page and insert an image but it was offset from the
top and left edges. My cover image is exactly 11x8.5, the same as my page
size and when I inserted the picture, it didn’t “fit” correctly. Even
scaling the picture down so it was smaller than the page didn’t fix the
problem, I still ended up with extra white space on the top and left and the
picture not centered on the page. I solved it by saving my cover image as a
PDF in Photoshop and then replacing the page in Acrobat. I think it makes
the final file size larger than it should be though.
|
The problem here is that the PDF library limits things to specific page sizes,
*and* those page sizes are in centimeters, not inches. When you specify a size
LPub finds the closest page size from this list
http://doc.qt.nokia.com/4.5/qprinter.html#PaperSize-enum
that wholly encloses the page size you specified.
8.5x11 is a little smaller than its metric counterpart.
Someday I’ll figure out one of two things: how to do custom page sizes, or
create a drop down list of only the sizes you can use.
Kevin
|
|
|
|
qs, qt
(score: 3.960)
|
More: Next Page >>
|
