klugily

comparative more klugily · superlative most klugily

1. alternativeAlternative form of kludgily.

   There were several articles in the first and second year of MacTutor that convered^([sic]) the programming interface. Here's some C I recently wrote that (klugily) calls them: […]

   1992 April 6, Charles B. Cranston, “PAP - where is programming info?”, in comp.sys.mac.programmer (Usenet), archived from the original on 06 Jun 2025

   4 more examples

   To summarize, we had a 64180 ICE. The original person who bought it got so discouraged they gave up and used some other methods. When I came to use it a year later, I was a bit more persistent and got it sortof^([sic]) working. However, both the hardware and software had a number of major and minor bugs. Some I could work around; one hw bug I even managed to klugily fix.

   1994 March 13, Michael Dunn, “ICE for Z80”, in comp.os.cpm (Usenet), archived from the original on 06 Jun 2025

   Anyway, this looks basically like a database programming job, yes? Except that the major datum in each record will be the charter, and we do *NOT* want to have to retype the charter (which is what my too-many years of data entry experience implies we'd have to do with database programs). After all, cut-and-paste should be available on pretty much any system (albeit perhaps klugily in Unix, where something like awk might be better).

   1997 August 30, Joe Bernstein, “Text fields to HTML without (much) database programming?”, in comp.infosystems.www.authoring.tools (Usenet), archived from the original on 06 Jun 2025

   I have just finished making a lo_create() function that accepts the desired large object OID to create, as per recent discussion. This means we can substantially reduce the complexity of pg_restore's handling of LOs: we can remove the code that (tediously and rather klugily) tries to find and update large object references in the database to refer to their new OIDs. Instead, we just restore the large objects with their original OIDs to begin with.

   2005 June 13, Tom Lane, “Implications of lo_create() for pg_dump”, in pgsql.hackers (Usenet), archived from the original on 06 Jun 2025

   The global bool InRecovery is only maintained correctly in the startup process, which wasn't a problem before 8.4. However, if we are making the bgwriter execute the end-of-recovery checkpoint, there are multiple places where it is tested that are going to be executed by bgwriter. I think (but am not 100% sure) that these are all the at-risk references: XLogFlush / CheckPointMultiXact / CreateCheckPoint (2 places) / Heikki's latest patch deals with the tests in CreateCheckPoint (rather klugily IMO) but not the others.

   2009 June 25, Tom Lane, “[BUGS] BUG #4879: bgwriter fails to fsync the file in recovery mode”, in pgsql.bugs (Usenet), archived from the original on 06 Jun 2025