dw_dev | Entries tagged with coding

So if anyone who uses the Rich Text editor when posting an entry was trying to insert a link to a github user, and wondered why it didn't look like Github was in the list, when you could have sworn you'd seen it in a recent code tour...

... it isn't.

"Github" is not in that list.
"github", however, is. Lower-case. And since that list sorts capital letters first (all capitals before all lower-case, according to an ancient table), this means that "github" goes down to the bottom of the list, below YouTube.

In dw-free/cgi-bin/DW/External/Site/Github.pm

line 19 is:

package DW::External::Site::github;

Which ... I wrote! Hooray! (Oops.)

( Some troubleshooting process. )

mark

I've created release-1.17 branches in both repos in preparation for tomorrow's code push. If you have anything you really want to land in tomorrow's code push, please let me or fu know and we'll see if we can get it in before then.

This frees the develop branch for continuing development. Anything that lands there will be slated for release in the NEXT code push (which will hopefully be next week, on account of next week being OSCON, and our typical enjoyment of Conference Driven Development).

deborah

denise asked me to put together a list of bite sized bugs: bugs that, assuming you already have a basic environment set up, will be quick and easy fixes. A couple of quick disclaimers:

Obviously one person's two-minute bug is another person's introductory programming project. There is a lot of guesswork in making this list. I am targeting for bugs that will take a minute or two for people who know the relevant part of the code fairly well, but won't be out of the reach of anyone who wants to do something introductory. In other words, I'm trying to avoid some of the more obscure parts of the code base.

Some of these bugs I am completely guessing on the difficulty. For example, I don't know, say, the poll code myself, but it looks like a pretty straightforward bug. If you take on one of these bugs and you find an unholy tangle of spaghetti code from R'lyeh's malignant depths, the failure is all mine. (Well, all mine, and whoever created the unholy tangle of spaghetti in the first place. Entirely possibly that person was also me. /o\) Seriously, I took something that looked tiny to me off this list after allen laughed a hollow, bitter laugh at its inclusion. Well, he was on IRC and he just said "no, it's not small," but the sentiment was clear.

( Bugs here! Get your list of bugs here! )

dunvi

I was looking at two seemingly similar bugs: bug 3838 and bug 3839, both of which have to do with breaking out JS (and in the case of 3838 CSS) from BML pages.

There was some talk of possibly porting the whole thing to the TT, but, gotta say, there are probably easier ones to start learning TT on!

Anyway. 3838 went fine - easy enough to remove the JS and CSS and move them into their own files. 3839 is a different story. Though the two look very similar, the way the JS is both implemented and then used is very different, and after a lot of thinking and futzing around, I have come to the conclusion that I cannot simply move the JS to a different file and tell the BML file where to find the JS.

In both cases, the JS is looking for information in the associated .text file. In 3838, this isn't important, because what the JS did was generate the HTML to be inserted into the page, which means that the perl inside still had a chance to be read properly. In 3839, the JS is causing actual events - for example, pop-ups asking you to input a name.

I guess there's several ways, then, to 'solve' this particular page. The easiest one is to leave it be and say "The javascript's just stuck". The hacky solution is to alter three of the javascript functions so that they take in some inputs, pre-gather the information from the .text file, and pass it to the javascript functions. Perhaps the correct answer is to rewrite the JS entirely, at which point I would say "Teach me how to convert this to TT".

Surely this problem has been encountered before?

foxfirefey

Bug 3532, the jQuerify journals bug, is moving towards completion. On the next code push, there will be a post to

dw_beta for any remaining issues people are having. They'll be fixed and/or filed, depending on urgency, so that we can then turn on the jQuery for everyone, while still giving people a chance to turn the jQuery off. I imagine once all the issues are taken care of, the old journal Javascript will be deprecated and then removed.

For development, this means patches for old journal Javascript will no longer be accepted. If you see a bug open for old journal JS, it can be closed. (Don't do that if it's something that involves doing JS for the new JQuery version, though.)

( Extra info on: Why JQuery-izing? )

brainwane

I'm helping run a hackathon in San Francisco in two months, and wanted to let Dreamwidth developers know about it in case you want to come!

Developers in the Bay Area and Silicon Valley, you can create cool hacks with and on Wikipedia. Our first San Francisco hackathon is happening Jan. 20-22, and we'll be there teaching you about MediaWiki (our software), about our API and about our framework for JavaScript feature development. Learn to reuse Wikipedia content in your own apps, create new functionality for every Wikipedia user around the world, or just tailor your own experience.

We're going to create a registration form really soon but I wanted to tell you about this so you can put it on your calendar.

I figure you folks have better ideas for Wikipedia integration than I do (I didn't see any in Bugzilla but maybe they aren't there yet?). I know there's a WordPress plugin, PhotoCommons, that makes it easy for bloggers to browse Wikimedia Commons for freely licensed images to dress up their posts. Maybe replicating that functionality in Dreamwidth would be cool? I've added it to the Suggestions queue.

Of course you don't need to come to the event to work on MediaWiki or on integration with Wikimedia sites -- our site has an intro tutorial and we are on IRC at #mediawiki on FreeNode and so on. But if you came to the event, that would be cool too. Open data!

jeshyr

[This ended up being sorta like a walkthrough-in-progress ... I'll turn it into a proper walkthrough if I ever finish it!]

Initial pokings at bug 1964 - taglists truncated when crossposting.

First I tried looking at the LJ code and found Changeset 9887 coded by

zorkian himself about 5 years ago. I couldn't figure out how that code could produce the results noted in the support requests though.

Secondly I tried setting up crossposting from my Dreamhack to Dreamwidth itself to see if I could replicate the bug because it seemed it would be easier to isolate if it was in the DW code too. Apparently it does happen in the DW code too which is handy ... these are the tests I ran:

Test 1: Non-new tags
( tag text in various states )

Test 2: New Tags
( tag text in various states )

Test 3: Longer New Tags
( tag text in various states )

Conclusions so far:

This happens between two DW instances so it's not an LJ-specific bug

It doesn't matter if the tag is new to the system or not

Tag length is not significant, only string length

The raw tag string is being truncated at 254 characters. I got 253 a few times but both times there was no truncated tag so I hypothesise the 254th character was a space on those occasions.

So something in the protocol is truncating this string at 254 characters either before it leaves the sending system, or before the receiving system has a chance to parse the string into an array of tags.

The code for the protocol used by the crossposting system is largely LJ::Protocol, stored in $LJHOME/cgi-bin/ljprotocol.pl.

... at this point I vaguely remember seeing something else potentially relevant in the LJ changesets I waded through so I go back and discover Changeset 9767 and poke at weblib.pl.

It indeed seems that we do still have this limit in DW, it's line 2192 at the moment so I delete the limit and restart everything.

Results now on DW are .... exactly the same.

At this point I am thinking throwing things is an attractive option so I am posting this ...

HALP!

[ETA: OMG headdesk headdesk ... realised literally 1 second after I pressed post of course: I need that patch on the *receiving* system not the sending one! I'm testing the wrong THING... back to the checking board for me.]

kareila

With global warnings on, some permutation of these lines shows up in the log whenever I hit an S2 page:

Constant subroutine S2::PROPS redefined at /usr/share/perl/5.8/constant.pm line 103.
Constant subroutine S2::STATIC redefined at /usr/share/perl/5.8/constant.pm line 103.
Constant subroutine S2::VTABLE redefined at /usr/share/perl/5.8/constant.pm line 103.

Any ideas as to why this might be happening?

aphenine

I was idly musing on my journal that DW is approaching the MVC model of web development, as it's got Controllers, in the form of functions that get called to handle pages, and Views in the form of the Template Toolkit (or even BML). It even has Routing (which doesn't get a letter in MVC ;) ) to bind the right url to the right Controller. What DW doesn't have is the M part, the Model, which is normally a class that handles access to a table in a database, and I was musing about this because some of the functionality would have been a bit useful for the work I was doing then, even if I do enjoy the fact that not fitting into the MVC concept means DW is a bit more freeform. Anyway, I was wondering if there was any reason that DW didn't have a Model class.

denise suggested that I ask, as often something doesn't exist because nobody's done it yet.

Do you think that a general database interface class, like a Model would be useful to DW? Do you think DW should go that way, or are people genuinely happy just hard-coding their SQL queries in various objects, as is done now? Admittedly, the DBI layer does a lot of what Models do, such as quote escaping and input sanitisation, although it doesn't quite do the same job, and it won't error check your SQL query input to check whether you are using the right fields and values, or automatically make your SQL queries for you if you provide it with sensible data and want to do a common operation. If something like a Model is useful, how far should one go with them? Do you find things like behaviours and relationships useful, or do they just get in your way?

Further, if I wrote a simple Model class, would anyone other than me use it? Would anyone know how? Would anyone even care? ;)

( Some concrete examples for people without any experience of MVC, to give you an idea of how it works (based on CakePHP's method of doing things, it's not exactly standardised). Unfortunately, MVC is a bit too much of a concept to explain quickly so forgive the jargon and crash course, better if you read up on it :( )

Current Music: TM Revolution - Invoke

kareila

I appreciate all the feedback I got on my previous post. Here's my thinking based on the comments there:

Tag list: wait for the new update page. The LJ implementation looks pretty buggy anyway, judging from initial reports.

Tag search: yes, we should make a GUI the primary interface to tag search on our site. It should:

* support complex boolean operations
* use either a POST to avoid the URL parsing problem, or an entirely new URL format (since you can't bookmark the result of a POST), or possibly both
* allow you to search for tags in more journals than just your own, as a paid feature (which means it should be a site page like "Manage Tags", not a journal page)
* allow further refinement of results based on date range and/or security level, possibly even mood (yes, that has already been suggested elsewhere)

However, that should be a new bug (or several bugs), perhaps more accurately titled "Metadata Search" to complement the existing Content Search. It need not immediately replace the basic tag search we inherited from LJ, which was never so ambitious.

A codemerge from LJ, if possible, would close the existing bug (which came from suggestions) for fixing the basic URL search in the current syntax, with added support requested for using ALL as the keyword instead of AND (although we should allow both for compatibility). If our code has changed too much to merge, or if it proves difficult to take only that part of the change and leave out the tag list code, we could reconsider whether it's worth the effort - but compared to the "all that and a pony" spec outlined above, it seems simple enough.

I think this approach would give us a usable (if "ugly") short term solution with minimal effort for the most basic use case, plus space to plan for a better long term solution in the future.

kareila

LJ just unveiled two features I've wanted here but haven't known how to implement, which are a tag list on the update page, and searching for multiple tags using AND instead of OR.

For the first, am I to assume that the new update page will support this, so we don't need to bother with trying to patch the feature into the old update page? Or perhaps rather that the new update page won't support it immediately, but it will be such a radical change that we shouldn't even bother working on it until then? (I really want this ASAP, and it has appeared on "most wanted".)

For the second, should we roll our own fix adopting LJ's URL syntax, or attempt a codemerge? Here's the syntax for those who missed the announcement:

http://username.livejournal.com/tag/tag1,tag2?mode=and
http://username.livejournal.com?tag=tag1,tag2&mode=and

The URL syntax was what bogged us down on that bug, and this seems like a reasonable solution, plus it's what users of both sites will come to expect.

Links to our Bugzilla:

http://bugs.dwscoalition.org/show_bug.cgi?id=581 (for the tag list)
http://bugs.dwscoalition.org/show_bug.cgi?id=1585 (for multiple tag search)

denise

A comment made in Bugzilla this morning had me thinking: what are the variables we use by convention (or should use) everywhere throughout the code? I want to make a list of them so that a) people can know what they are and not re-use them for other things, and b). we can go through and change things that don't use them.

The ones I immediately thought of are:

$u: user object
$remote: remote logged-in viewer

What else is there? (And if there isn't a convention for a specific reference, and it's got five or six variable names throughout the code, mention that too, so we can standardize.)

So, I just committed a code merge for an issue we found via LJ, where comment properties weren't being deleted when the comment was.

That takes care of new properties, but we still have old ones hanging around! How do we handle this? I'm assuming that due to the size of talkprop2, doing:

delete talkprop2 from talkprop2, talk2 where talkprop2.journalid=talk2.journalid AND talkprop2.jtalkid=talk2.jtalkid AND talk2.state="D";

would be a horrible idea, but what can we do to make it less horrible? Should we even try to delete?

pauamma

LJ::Typemap calls LJ::MemCache, but doesn't actually "use LJ::MemCache;" or call LJ::MemCache::init, relying instead on ljlib.pl to do both. In web context, ljlib.pl is loaded through Apache::LiveJournal, and for worker processes, through LJ::Worker::Manual. For other executables (eg, proof of concept, throwaway learning tools, etc) which don't fall in either category, what should happen?

Options are:
1- Make LJ::Typemap (and everything else that relies on LJ::MemCache) use it and initialize it explicitely. This requires changes to LJ::MemCache, because LJ::MemCache::init isn't currently idempotent.
2- Require all programs using LJ::MemCache to use base 'LJ::Worker::Manual'; (but that in turn requires making them workers, with a LJ::Worker::Foo package that's started from main, which is awkward for throw-away programs).
3- Make LJ::MemCache initialize itself when loaded, and remove explicit initialization from everywhere else that uses it, but that's extensive.
4- Something else I forgot.

I'm leaning toward 2 ATM. Anyone has a better solution, an opinion, or comments?

namanhams

Hi ,

According to here wiki.dwscoalition.org/notes/Main_development_folder : "anything that appears at http://www.dreamwidth.org/filename.bml will be here, as

htdocs/filename.bml" 

But the link to the "Reading page" is :  "YourUserName.dreamwidth.org/read", which i can not find any "read" folder or "read.pl" file in the dw folder.

There are some similar links that i can not find the source file :

"

YourUserName.dreamwidth.org/calendar" -> link to "Archive"

"

YourUserName.dreamwidth.org/"   -> link to "Recent entries"
......

Please help to clarify for me. Thanks a lot.

yvi

Can any of you more experienced people tell me roughly when it is a good idea to write a TheSchwartz-scheduled Worker? Looking at the workers in existence, it's for things that need to work on all users or all clusters (latest feed, invite code distribution, userpic renaming), things that can take a long time (importer) or that don't need to happen instantly and may need to be tried a few times (crossposting).

I am asking both for curiosity and because I am working on merging tags (taking a list of tags and for each entry with that tag, adding the new tag is added and deleting the old tags), which I think is not such a heavy load that it would require a worker, but I thought I'd ask.

pauamma

Since we use Storable for our shopping carts (*), can
http://community.livejournal.com/lj_maintenance/127592.html (the 2.12/2.15/2.21 thing) affect us too? Either between production servers or when going from dreamhacks to production?

More generally, should we have a list of minimum/approved/recommended module versions? Or an official, mandatory, warranty-void-if-you-use-something-else version for each 3rd party module we use directly or indirectly?

(*) And for other things too IIRC - community moderation queues and entry drafts come to mind.

kareila

When I was doing some code cleanup a few months ago, I saw some lines that looked like this:

my $foo;
$foo = $bar unless $baz;

I decided that looked redundant and changed it to:

my $foo = $bar unless $baz;

Take my advice: don't combine "my" statements and postfix conditionals. Ever.

I've updated the programming guidelines to warn people away from this as well.

( Brief explanation of why this is a bad thing )

Current Mood: embarrassed

foxfirefey

Hey people, I'm sprucing up Gradation Vertical's appearance in places (with the bonus side effect of improving site themes in general). Bugs I have patches for or will shortly have patches for include:

Bug 878 - Inbox has tropo-red colours hard-coded -- This is where the folder you've selected in the inbox is pink no matter what.
Bug 1255 - Some settings text too dark in Gradation -- Some settings pages are black on black and not readable
Bug 2238 - Gradation Vertical Support unreadable or not dark schemed -- The Support area is not well themed and the Support Board nigh unreadable.
Bug 2243 - Adult content div box colors hardcoded -- not sure what colors to end up making these for all the different schemes (suggestions appreciated), but the adult content page has the warning box color hardcoded to something unreadable on Gradation Vertical.

If anybody else is using Gradation Vertical, please let me know if you run into any awkwardly styled spots not mentioned above.

Hopefully this will also help lead to Gradation Horizontal--

denise has the mockups still, and the logo done for Gradation Vertical should work for Gradation Horizontal! The bug for that is here.

ETA: Other bugs filed:

Bug 2204 - RTE on update page does not display properly in gradation-vertical

jadelennox

cgi-bin/LJ/Widget/CreateAccount.pm is full of references to a variable named $alt_layout. However, aside from in the accompanying CreateAccount JavaScript and i18n files, $alt_layout is never mentioned in the code. I can certainly not see where it gets passed to CreateAccount.pm in order to get taken in as an option:

my $alt_layout = $opts{alt_layout} ? 1 : 0;

What is this variable for? How does it get passed to CreateAccount? What does it mean?

Thanks very much.

Profile

Dreamwidth Open Source Development

May 2025

S	M	T	W	T	F	S
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

Syndicate

Page Summary

azurelunatic - I did it! I broke the site! ... just a little... with a little bit of WTF-8.
mark - Release branch 1.17 created
deborah - Bite sized bugs. Like delicious doughnut holes of fixes for you to devour.
dunvi - about refactoring (aka oh right i need a title)
foxfirefey - jQuerify journals status
brainwane - San Francisco Wikipedia hackathon, Jan. 20-22, and Wikimedia integration ideas for DW
jeshyr - Bug 1964: What should I do next?
kareila - S2 constant errors
aphenine - Models
kareila - LJSV-1068 redux
kareila - LJSV-1068
denise - variable conventions
fu - Batch processing of huge tables
pauamma - Using LJ::Typemap outside web context: how to initialize LJ::MemCache?
namanhams - Dreamhack : question about structure of directory
yvi - When to use a Worker?
pauamma - Version s of Storable.pm (and other required 3rd-party modules)
kareila - the hazards of coding for webservers vs. shell scripts
foxfirefey - Sprucing up Gradation Vertical
jadelennox - alt_layout in CreateAccount.pm?

Active Entries

1: Question thread #141
2: Question thread #140
3: Question thread #139
4: Question thread #138
5: Code tour for 2023-11-22 to 2024-11-30
6: Question thread #137
7: Question thread #135
8: Current Code Contributors: November 2024
9: Patching Mood Themes
10: Question thread #134

Style Credit

Style: Lettuce for Crossroads by branchandroot
Resources: P r o l o g u e

Expand Cut Tags

No cut tags

Page generated Jun. 6th, 2025 12:26 pm

Dreamwidth Development

Entries tagged with coding

I did it! I broke the site! ... just a little... with a little bit of WTF-8.

Release branch 1.17 created

Bite sized bugs. Like delicious doughnut holes of fixes for you to devour.

about refactoring (aka oh right i need a title)

jQuerify journals status

San Francisco Wikipedia hackathon, Jan. 20-22, and Wikimedia integration ideas for DW

Bug 1964: What should I do next?

S2 constant errors

Models

LJSV-1068 redux

LJSV-1068

variable conventions

Batch processing of huge tables

Using LJ::Typemap outside web context: how to initialize LJ::MemCache?

Dreamhack : question about structure of directory

When to use a Worker?

Version s of Storable.pm (and other required 3rd-party modules)

the hazards of coding for webservers vs. shell scripts

Sprucing up Gradation Vertical

alt_layout in CreateAccount.pm?

Profile

May 2025

Syndicate

Most Popular Tags

Page Summary

Active Entries

Style Credit

Expand Cut Tags