API tools faq
paste
ngbmameman

Untitled

ngbmameman
Jul 20th, 2012
323
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 58.46 KB | None | 0 0
raw download clone embed print report
  1. Jul 20 19:01:03 <Suner> which just about no one posted...
  2. Jul 20 19:01:15 <thearrowflies> !@#$%^
  3. Jul 20 19:01:15 * TheDuceCat has changed the topic to: The meeting has begun. First order of business is agreeing on code guidelines to use for the project.
  4. Jul 20 19:01:24 <thearrowflies> people posted in the subreddit
  5. Jul 20 19:01:45 <The_Mango> I think we just need basic guidelines
  6. Jul 20 19:01:55 <The_Mango> Like, make sure to keep stuff indented.
  7. Jul 20 19:02:00 <TheDuceCat> we want to make sure stuff is uniform
  8. Jul 20 19:02:14 <TheWalkingDerp> the top comment in that thread covers the basics pretty well
  9. Jul 20 19:02:25 <TheDuceCat> Suner's guideline submission is good
  10. Jul 20 19:02:39 <The_Mango> variable names in camelCase can get very hard to read though
  11. Jul 20 19:02:53 <The_Mango> Especially if you need longer length ones
  12. Jul 20 19:02:54 <TheDuceCat> i've gotten used to it over the years
  13. Jul 20 19:02:56 <Suner> ^have never found that to be a problem
  14. Jul 20 19:03:00 <miyako> yeah, other than the stuff that is not applicable to C I think that Sunar's submission is mostly good
  15. Jul 20 19:03:21 <miyako> I personally prefer underline_as_a_separator but I'm okay with camelCase
  16. Jul 20 19:03:31 * SlimTim10_ is now known as SlimTim10
  17. Jul 20 19:03:35 <TheDuceCat> do you want to take a poll?
  18. Jul 20 19:03:44 <Kobono> poll time!
  19. Jul 20 19:03:48 <TheDuceCat> alright
  20. Jul 20 19:03:55 <FRodrigues> wait!
  21. Jul 20 19:04:03 <FRodrigues> i need to read first
  22. Jul 20 19:04:20 <TheDuceCat> we'll start the poll now
  23. Jul 20 19:04:22 <The_Mango> We're polling just on variable names right now
  24. Jul 20 19:04:24 <TheDuceCat> say 'underscore' if you want underscores, 'camelCase' if you want camelCase
  25. Jul 20 19:04:32 <Kobono> camelCase
  26. Jul 20 19:04:32 <The_Mango> underscore
  27. Jul 20 19:04:33 <Gabe1118> camelCase
  28. Jul 20 19:04:34 <TheWalkingDerp> underscore
  29. Jul 20 19:04:36 <thearrowflies> cC
  30. Jul 20 19:04:36 <centigrade233> camelCase
  31. Jul 20 19:04:39 <miyako> underscore
  32. Jul 20 19:04:46 <TheDuceCat> camelCase
  33. Jul 20 19:04:50 <TheDuceCat> wow that was mixed
  34. Jul 20 19:04:58 <Kobono> camelCase is one ahead I think
  35. Jul 20 19:05:01 <TheDuceCat> so far a 4-3 for cC
  36. Jul 20 19:05:14 <thearrowflies> 5-3?
  37. Jul 20 19:05:22 <Suner> it's 5-3
  38. Jul 20 19:05:23 <TheDuceCat> yeah
  39. Jul 20 19:05:24 <TheDuceCat> 5-3
  40. Jul 20 19:05:30 <TheDuceCat> didn't count myself!
  41. Jul 20 19:05:32 <Suner> any other voters?
  42. Jul 20 19:05:35 <TheDuceCat> anyone else?
  43. Jul 20 19:05:36 <centigrade233> the score is q to 12
  44. Jul 20 19:06:05 <Kobono> Is anyone writing down on what we agree?
  45. Jul 20 19:06:10 <TheDuceCat> anyone?
  46. Jul 20 19:06:10 <thearrowflies> im logging
  47. Jul 20 19:06:13 <TheDuceCat> ^
  48. Jul 20 19:06:20 <The_Mango> Well, so far it's just waht Suner said
  49. Jul 20 19:06:22 <miyako> I'm keeping track mentally and will review the log and post a summary
  50. Jul 20 19:06:22 <The_Mango> No need yet
  51. Jul 20 19:06:37 <Suner> sooo
  52. Jul 20 19:06:43 <Suner> I guess that means no more voters?
  53. Jul 20 19:06:48 <FRodrigues> i vote in cC
  54. Jul 20 19:06:53 <TheDuceCat> k
  55. Jul 20 19:06:55 <TheDuceCat> LAST CALL
  56. Jul 20 19:06:59 <miyako> so do we want to use the same convetion for C, with modifications where necessary (e.g. remove references, default values, classes)
  57. Jul 20 19:07:07 <FRodrigues> it's more widely used
  58. Jul 20 19:07:16 <Kobono> miyako: I'd say yes
  59. Jul 20 19:07:29 <Kobono> miyako: consistency across languages is nice
  60. Jul 20 19:07:35 <TheDuceCat> ^
  61. Jul 20 19:08:04 <TheDuceCat> what do you guys think about the opening brace on the same line for one statement
  62. Jul 20 19:08:07 <TheDuceCat> rule # 9
  63. Jul 20 19:08:14 <Kobono> lemme check
  64. Jul 20 19:08:28 <thearrowflies> after the meeting is done, does some one want to post a short piece of code demonstrating what we decided?
  65. Jul 20 19:08:31 <thearrowflies> um
  66. Jul 20 19:08:53 <Kobono> I think #9 is fine
  67. Jul 20 19:08:53 <Suner> actually, in case it's unclear #9 just says it HAS to have braces (whether on same line or it's own)
  68. Jul 20 19:08:54 <thearrowflies> i generally put it on the line of the function but its fine on a new line
  69. Jul 20 19:08:55 <FRodrigues> i vote against rule 9!
  70. Jul 20 19:08:57 <miyako> thearrowflies: I think Suner has pretty good examples in there
  71. Jul 20 19:09:01 <The_Mango> For class and function declarations yes
  72. Jul 20 19:09:19 <The_Mango> for flow control, no
  73. Jul 20 19:09:25 <The_Mango> if(){
  74. Jul 20 19:09:26 <TheDuceCat> i myself prefer braces on own lines at all times
  75. Jul 20 19:09:30 <The_Mango> clas Name
  76. Jul 20 19:09:31 <The_Mango> {
  77. Jul 20 19:09:39 <Kobono> I prefer egyptian notation
  78. Jul 20 19:09:55 <Suner> ^ I lol'd
  79. Jul 20 19:10:02 <miyako> As long as we don't use gnu notation I'm fine
  80. Jul 20 19:10:17 <TheDuceCat> so make it an option to have the brace on same line?
  81. Jul 20 19:10:18 <Kobono> http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html
  82. Jul 20 19:10:20 <ArrowBot> Title: Coding Horror: New Programming Jargon (at www.codinghorror.com)
  83. Jul 20 19:10:24 <Kobono> number 3
  84. Jul 20 19:10:25 <TheDuceCat> with one staement
  85. Jul 20 19:10:41 <thearrowflies> i say its an option
  86. Jul 20 19:10:45 <The_Mango> option
  87. Jul 20 19:10:58 <Kobono> We're talking about the opening braces right?
  88. Jul 20 19:11:01 <TheDuceCat> yep
  89. Jul 20 19:11:06 <TheDuceCat> same line option for one staement
  90. Jul 20 19:11:10 <TheDuceCat> same line option for one statement
  91. Jul 20 19:11:24 <Suner> btw, what I wrote in the guideline is, the rule is that a control structure MUST have braces, it doesn't say anything about having the brace on the same line
  92. Jul 20 19:11:42 <Kobono> we're sicussing #10 then
  93. Jul 20 19:11:45 <TheDuceCat> yeah i misread it the first time
  94. Jul 20 19:11:47 <miyako> e.g. if (something) { doSomething(); } ?
  95. Jul 20 19:12:07 <TheDuceCat> ehh one liner conditionals
  96. Jul 20 19:12:50 <TheDuceCat> any other inquiries about Suner's post?
  97. Jul 20 19:12:53 <miyako> I'm okay with one-line conditionals, they can sometimes make code more readable if you are doing a lot of input validation at the start of a function
  98. Jul 20 19:13:21 <Kobono> what about functions? camelCase or underscores?
  99. Jul 20 19:13:29 <FRodrigues> camelCase
  100. Jul 20 19:13:40 <TheDuceCat> camel
  101. Jul 20 19:13:40 <Kobono> underscore
  102. Jul 20 19:13:46 <FRodrigues> try to stay in one topic :S
  103. Jul 20 19:13:50 <The_Mango> camel case
  104. Jul 20 19:13:58 <TheDuceCat> it is on topic
  105. Jul 20 19:14:27 <thearrowflies> 21: im against using namespace std; but could we do using std::cout; ?
  106. Jul 20 19:14:44 <FRodrigues> why we dont start with the first rule and vote?
  107. Jul 20 19:14:45 <Kobono> thearrowflies: I agree
  108. Jul 20 19:14:45 <Suner> no
  109. Jul 20 19:15:23 <thearrowflies> why not Suner?
  110. Jul 20 19:15:44 <miyako> related to 22, should we have something like "avoid function-like macros in favor of inlined functions"
  111. Jul 20 19:15:44 <Suner> it's really just for clarity sake, not importing anything from std::
  112. Jul 20 19:16:17 <TheDuceCat> keeps everything neat in its namespace
  113. Jul 20 19:16:48 * Kennythehitman has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
  114. Jul 20 19:16:53 <Suner> to be clear, I only mean for it to apply to the standard namespace
  115. Jul 20 19:17:14 <Kobono> miyako:Why are inline functions preferred though?
  116. Jul 20 19:17:26 <Suner> Kobono: macros are evil
  117. Jul 20 19:17:31 <Kobono> Why?
  118. Jul 20 19:17:42 <Suner> they don't follow the rules of the language
  119. Jul 20 19:17:47 <Suner> they have completely global scope
  120. Jul 20 19:18:08 <Suner> and will just replace, effectively a dumb search and replace
  121. Jul 20 19:18:19 <miyako> Kobono: the compiler can often make a better decision on whether to inline or not than the programmer can, it's easier to debug, and function-like macros can turn really nastly if you start doing token generation
  122. Jul 20 19:18:49 <miyako> plus there are a lot of bugs you can introduce if you don't handle them correctly, e.g. while(0) { ... }
  123. Jul 20 19:19:15 <Kobono> then inline functions are obviously the way to go
  124. Jul 20 19:19:18 <Suner> #define SIZE radius*2+1
  125. Jul 20 19:19:22 <Suner> SIZE*2
  126. Jul 20 19:19:24 <Suner> oops
  127. Jul 20 19:19:56 <miyako> there are some cases where function like macros make sense, but I'd say that given the goal of keeping the code simple we should treat them as special cases
  128. Jul 20 19:20:13 <thearrowflies> yeah
  129. Jul 20 19:20:18 <Kobono> Do they make sense for magic numbers?
  130. Jul 20 19:20:29 <Suner> as I general rule I just say: "can you do it without a macro?"
  131. Jul 20 19:20:41 <Kobono> So constants are better
  132. Jul 20 19:20:42 <Kobono> ?
  133. Jul 20 19:20:43 <The_Mango> Depends what kind of magic number
  134. Jul 20 19:20:43 <Suner> Kobono: that's what constants are for
  135. Jul 20 19:21:38 <Kobono> I have a proposal for c
  136. Jul 20 19:21:52 <Kobono> structs should always be defined with a typedef
  137. Jul 20 19:21:57 <thearrowflies> TheDuceCat: we are using qt creator for the gui and the coding correct?
  138. Jul 20 19:22:00 <miyako> I typically use macros for numbers that could change at compile time (e.g. MAX_STACK_SIZE), and function-like macros for bit-twiddling
  139. Jul 20 19:22:03 <TheDuceCat> yes thearrowflies
  140. Jul 20 19:23:02 <Suner> too bad C doesn't have constexpr
  141. Jul 20 19:23:02 <miyako> Kobono: typically I forward-declare the struct, create the struct, and then create a typedef for it if it's going to be used as a type
  142. Jul 20 19:23:38 <Kobono> miyako: I don't fully understand, could you give an example?
  143. Jul 20 19:25:16 <miyako> Kobono: yeah, so typically I'll do something like
  144. Jul 20 19:26:07 <miyako> struct mystruct { ... };
  145. Jul 20 19:26:20 <miyako> then, if I'm going to use it as an opaque type, I'll create a mystruct_t for it
  146. Jul 20 19:26:30 <miyako> but if it's just going to be used as packed data, I won't
  147. Jul 20 19:26:40 <Suner> I like this
  148. Jul 20 19:26:57 * calzone21 (ae5811cf@gateway/web/freenode/ip.174.88.17.207) has joined #rpcdesktop
  149. Jul 20 19:27:05 <miyako> but I avoid using: typdef struct { } mystruct_t;
  150. Jul 20 19:27:23 <Kobono> I'm fine with that
  151. Jul 20 19:28:41 <Suner> ssoo next?
  152. Jul 20 19:28:48 <miyako> I would like to have a vote on adding 2 rules to the convetion
  153. Jul 20 19:28:56 <TheDuceCat> go ahead
  154. Jul 20 19:29:24 <miyako> 1: prefer readability to convention - if you have a really good reason for violating the convetion, because it enhances readability, make a case for why and it can possibly be accepted
  155. Jul 20 19:29:58 <TheDuceCat> yeah but definitely depends on case
  156. Jul 20 19:29:59 <miyako> and 2: prefer consistency to convention. If for some reason a file exists that uses it's own convetion, it's better to keep the same convention within a file than to mix conventions
  157. Jul 20 19:30:09 <Suner> +1
  158. Jul 20 19:30:25 <thearrowflies> +1
  159. Jul 20 19:30:26 <TheDuceCat> what do you mean by #2
  160. Jul 20 19:30:34 <Kobono> +1
  161. Jul 20 19:30:55 <miyako> TheDuceCat: presumably, all the code we have should follow our coding convention, but if for whatever reason (say we included a file from another open source project, for example)
  162. Jul 20 19:31:05 <TheDuceCat> alright yeah that's good
  163. Jul 20 19:31:26 <Suner> no antivotes?
  164. Jul 20 19:31:49 * paise (0e634326@gateway/web/freenode/ip.14.99.67.38) has joined #rpcdesktop
  165. Jul 20 19:31:51 <FRodrigues> wait
  166. Jul 20 19:32:09 <miyako> I would like to take a moment on record to lol at the fact that suner was most opposed to coding conventions, and we're going to be using the one he wrote :)
  167. Jul 20 19:32:36 <FRodrigues> +1
  168. Jul 20 19:33:02 <Suner> lol, I only wrote one because nobody else seemed to...
  169. Jul 20 19:33:26 <The_Mango> I still don't think it needs to be this strict
  170. Jul 20 19:33:29 <miyako> Suner: yeah, I was going to write one before I got the plague
  171. Jul 20 19:33:42 <The_Mango> If someone wrote bad looking code someone else can fix it up and commit
  172. Jul 20 19:33:49 <calzone21> hey guys, sorry if it may have been mentioned already. say someone submits code that doesn't follow the convention?
  173. Jul 20 19:33:54 <Suner> The_Mango: and I agree
  174. Jul 20 19:33:58 <calzone21> ok i was a bit late on that
  175. Jul 20 19:34:00 <TheDuceCat> yeah but we're trying to keep a level of consistency
  176. Jul 20 19:34:06 <thearrowflies> calzone21: we deny it
  177. Jul 20 19:34:07 <The_Mango> Why don't we vote on that first?
  178. Jul 20 19:34:10 <Suner> here's the thing
  179. Jul 20 19:34:12 <thearrowflies> thats what we agreed on
  180. Jul 20 19:34:13 <The_Mango> Or has it already been voted on?
  181. Jul 20 19:34:15 <Suner> if someone submits code
  182. Jul 20 19:34:26 <Suner> that deviates from the convention a bit, but is otherwise good code
  183. Jul 20 19:34:32 <Suner> does it really deserve to be denied?
  184. Jul 20 19:34:46 <The_Mango> Not at all
  185. Jul 20 19:34:47 <paise> IMO no.
  186. Jul 20 19:34:55 <TheDuceCat> well it needs to be fixed first
  187. Jul 20 19:34:58 <TheDuceCat> then it can be accepted
  188. Jul 20 19:34:59 <calzone21> should we consult them on what mistakes they made convention wise?
  189. Jul 20 19:35:03 <TheDuceCat> not like comletely blocked
  190. Jul 20 19:35:05 <TheDuceCat> yeah
  191. Jul 20 19:35:10 <Suner> not that I'm saying if you have someone who submits something with idents all over the place that it should be acceptable
  192. Jul 20 19:35:19 <calzone21> yeah, of course
  193. Jul 20 19:36:07 <Suner> I just don't think we should be pole-in-ass about it
  194. Jul 20 19:36:45 <TheDuceCat> no but it should be encouraged
  195. Jul 20 19:37:04 <Suner> yes, but ultimately I think different rules should hold different weights
  196. Jul 20 19:37:18 <calzone21> it has to be looked at like an assignment. are we going to have a team dedicated to testing/checking for things like this or is it open to anyone to act on it
  197. Jul 20 19:37:23 <TheDuceCat> we have to review it on an individual basis
  198. Jul 20 19:37:40 <Suner> e.g. let's say one of the rules says control structures MUST have braces
  199. Jul 20 19:37:53 <Suner> personally, I'm not going to crucify someone because they forgot a pair of braces
  200. Jul 20 19:38:00 <thearrowflies> .post link progcollab "sorryforthetest" http://i.imgur.com/sf9MK.jpg
  201. Jul 20 19:38:01 <ArrowBot> thearrowflies: An error has occurred and has been logged. Please contact this bot's administrator for more information.
  202. Jul 20 19:38:07 <TheDuceCat> no but they can edit it
  203. Jul 20 19:38:13 <The_Mango> I'd just expect someone else to go in and fix it
  204. Jul 20 19:38:17 <Suner> ^
  205. Jul 20 19:38:20 <Suner> it's not a big deal
  206. Jul 20 19:38:26 <The_Mango> Exactly
  207. Jul 20 19:38:26 <Suner> on the other hand
  208. Jul 20 19:38:35 <The_Mango> And it's not like every single commit is reviewed is it?
  209. Jul 20 19:38:38 <TheDuceCat> can't you update pull requests?
  210. Jul 20 19:38:47 <Suner> if a person is litering using namespace std; in all their header files
  211. Jul 20 19:38:48 <TheDuceCat> pull requests will be reviewed
  212. Jul 20 19:38:53 <Suner> of course I expect THAT to be rejected
  213. Jul 20 19:39:10 <TheDuceCat> you can patch pull requests i think
  214. Jul 20 19:39:11 <miyako> hey guys, need to go AFK for a few
  215. Jul 20 19:39:21 <TheDuceCat> k
  216. Jul 20 19:39:37 <FRodrigues> ok
  217. Jul 20 19:40:40 <calzone21> ok, sorry to deviate from main discussion. i wanted to see how we would handle these issues
  218. Jul 20 19:41:11 <Kobono> Weren't they already discussed in the reddit post?
  219. Jul 20 19:41:21 <Suner> nope?
  220. Jul 20 19:41:30 <Kobono> ok
  221. Jul 20 19:44:06 <Suner> are we in agreement about miyako's two proposals?
  222. Jul 20 19:44:14 <TheDuceCat> yes
  223. Jul 20 19:44:21 <thearrowflies> yeah
  224. Jul 20 19:44:42 <paise> Sorry was a bit late, which two?
  225. Jul 20 19:45:12 <Suner> <miyako> 1: prefer readability to convention - if you have a really good reason for violating the convetion, because it enhances readability, make a case for why and it can possibly be accepted
  226. Jul 20 19:45:12 <Suner> <miyako> and 2: prefer consistency to convention. If for some reason a file exists that uses it's own convetion, it's better to keep the same convention within a file than to mix conventions
  227. Jul 20 19:45:34 <calzone21> agreed
  228. Jul 20 19:45:41 <Kobono> yes
  229. Jul 20 19:45:46 <paise> yep
  230. Jul 20 19:46:49 <FRodrigues> +1
  231. Jul 20 19:48:18 <FRodrigues> what do you think about never declare a pointer and a regular type(?) in the same line, like int* ptr, i; ?
  232. Jul 20 19:48:26 <TheDuceCat> never
  233. Jul 20 19:48:32 <thearrowflies> ever
  234. Jul 20 19:48:36 <TheWalkingDerp> ever?
  235. Jul 20 19:48:43 <The_Mango> never ever
  236. Jul 20 19:48:45 <FRodrigues> never and ever!
  237. Jul 20 19:48:46 <TheWalkingDerp> ok
  238. Jul 20 19:48:47 <TheDuceCat> what about multiple pointers in one line
  239. Jul 20 19:48:48 <The_Mango> There's no point
  240. Jul 20 19:48:51 <Suner> one statement per line
  241. Jul 20 19:48:54 <The_Mango> no
  242. Jul 20 19:48:54 <TheDuceCat> ok
  243. Jul 20 19:48:56 <thearrowflies> yes
  244. Jul 20 19:48:58 <TheDuceCat> i'm absolutely fine with that
  245. Jul 20 19:49:06 <TheDuceCat> makes everything simpler
  246. Jul 20 19:50:16 <FRodrigues> int* ptr1,* ptr2; ?
  247. Jul 20 19:50:24 <TheDuceCat> one statement per line
  248. Jul 20 19:50:27 <The_Mango> FRodrigues: no
  249. Jul 20 19:50:29 <The_Mango> that'
  250. Jul 20 19:50:31 <The_Mango> s
  251. Jul 20 19:50:33 <The_Mango> bad
  252. Jul 20 19:50:37 <thearrowflies> blasphemy
  253. Jul 20 19:50:43 <Suner> int* ptr1;
  254. Jul 20 19:50:46 <Suner> int* ptr2;
  255. Jul 20 19:50:48 <TheDuceCat> i think if someone submits a pull request that isn't up to par they can just edit it what do you guys think?
  256. Jul 20 19:51:20 <FRodrigues> so many lines :P
  257. Jul 20 19:51:23 <thearrowflies> up to par in what sense?
  258. Jul 20 19:51:28 <The_Mango> things like, int* ptr1; vs. int * ptr1; shouldn't be grounds to not accept though
  259. Jul 20 19:51:47 <Suner> ^
  260. Jul 20 19:51:48 <TheDuceCat> yeah you're right
  261. Jul 20 19:51:54 <thearrowflies> that
  262. Jul 20 19:52:02 <TheDuceCat> but asking them to edit it isn't denying it in any way
  263. Jul 20 19:52:10 <TheDuceCat> well it kind of is :P
  264. Jul 20 19:52:19 <calzone21> yeah, but it lets them know what they did wrong
  265. Jul 20 19:52:39 <calzone21> which is good for the learning process.
  266. Jul 20 19:52:50 <TheDuceCat> we could say can you move that asterisk over one
  267. Jul 20 19:52:50 <The_Mango> it's not *wrong* though
  268. Jul 20 19:52:55 <TheDuceCat> and they can add another commit on top of it
  269. Jul 20 19:52:59 <TheDuceCat> and send it in no problem
  270. Jul 20 19:53:08 <TheDuceCat> it helps them learn to code on guidelines
  271. Jul 20 19:53:15 <calzone21> exactly
  272. Jul 20 19:53:41 <paise> On a reddit comment I had a suggestion of using astyle (http://astyle.sourceforge.net/) to conform with the whatver guidelines being agreed here. What do you think?
  273. Jul 20 19:53:42 <ArrowBot> (19/15)[22] "TIL there is a really easy automated way to change the formating of code to the way you like it." http://www.reddit.com/r/programming/comments/f35ix/
  274. Jul 20 19:54:55 <FRodrigues> is this correct?
  275. Jul 20 19:54:56 <FRodrigues> http://pastebin.com/thetxDw9
  276. Jul 20 19:54:59 <ArrowBot> Title: [C] Wrong: int y,x,i,j; int gRadius; double a0,a1,a2,a3,c; double *gauss; uchar - Pastebin.com (at pastebin.com)
  277. Jul 20 19:55:07 <thearrowflies> dont ides today have settings to change the way it auto formats things? people using comapatible ides should adjust it as needed
  278. Jul 20 19:55:31 <chancez> paise: in vim you can just gg=G
  279. Jul 20 19:55:40 <TheDuceCat> FRodrigues: looks good
  280. Jul 20 19:55:50 <chancez> or just properly set the settings.
  281. Jul 20 19:55:59 <Suner> FRodrigues, double a[4];?
  282. Jul 20 19:56:02 <thearrowflies> im not sure if it was mentioned, but
  283. Jul 20 19:56:23 <thearrowflies> i dont think we should declare all variables at the top of the function/whatever. Only when we need them
  284. Jul 20 19:56:35 <Suner> this is actually one of the reasons
  285. Jul 20 19:56:38 <Suner> I hate C89
  286. Jul 20 19:56:41 <paise> thearrowflies: yes, if it is so and if everyone's using compatible editors, then there is no need to use astyle.
  287. Jul 20 19:56:45 <The_Mango> If it's a small function, you might as well put them at the top
  288. Jul 20 19:57:00 <FRodrigues> Suner, yes
  289. Jul 20 19:57:14 <The_Mango> I say declare a set of variables at once whenever you come to a section that will be using them all
  290. Jul 20 19:57:23 <The_Mango> To keep from littering it with random declarations
  291. Jul 20 19:57:43 <Suner> I prefer the, declare near where you need them
  292. Jul 20 19:57:50 <The_Mango> *near*
  293. Jul 20 19:57:57 <Suner> yes near, not exactly before
  294. Jul 20 19:58:02 <The_Mango> But not neccessarily only right where you do
  295. Jul 20 19:58:05 <The_Mango> Exactly
  296. Jul 20 19:58:05 <thearrowflies> thats what i meant
  297. Jul 20 19:58:12 <thearrowflies> in my head
  298. Jul 20 19:58:28 <Suner> I mean if I have an if statement or assert at the start of my function
  299. Jul 20 19:58:36 <Suner> no, I'm not going to declare anything before them
  300. Jul 20 19:58:42 <TheDuceCat> alright so any other objections with Suner's comment?
  301. Jul 20 19:59:08 <TheDuceCat> declaring variables at certain locations isn't something to really put guidelines on i think
  302. Jul 20 19:59:28 <TheDuceCat> just more of a recommendation
  303. Jul 20 19:59:29 <Suner> I wouldn't actually expect many people to do something weird
  304. Jul 20 19:59:30 * WolfeL (4a4e4a9c@gateway/web/freenode/ip.74.78.74.156) has joined #rpcdesktop
  305. Jul 20 19:59:35 <Suner> when it comes to declaring
  306. Jul 20 19:59:45 <TheDuceCat> yeah
  307. Jul 20 19:59:48 <TheDuceCat> so any other objections?
  308. Jul 20 19:59:51 * Gabe1118 has quit (Quit: Leaving)
  309. Jul 20 19:59:57 <thearrowflies> nein
  310. Jul 20 19:59:58 <TheDuceCat> we need to push forward
  311. Jul 20 20:00:10 <FRodrigues> c99 permits for(int i=0;i<20;++i)?
  312. Jul 20 20:00:22 <TheDuceCat> yes
  313. Jul 20 20:00:23 <Suner> yes
  314. Jul 20 20:00:43 <TheDuceCat> so to be clear, no more objections?
  315. Jul 20 20:00:47 <The_Mango> I g2g
  316. Jul 20 20:00:49 <The_Mango> Peace
  317. Jul 20 20:00:49 <thearrowflies> no
  318. Jul 20 20:00:53 <FRodrigues> no
  319. Jul 20 20:00:53 <thearrowflies> bye
  320. Jul 20 20:00:54 * The_Mango has quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713224758])
  321. Jul 20 20:00:54 <Suner> later mango
  322. Jul 20 20:01:04 <TheDuceCat> alright then we'll use Suner's styles with the modifications we have discussed today.
  323. Jul 20 20:01:12 <TheDuceCat> shall we move on?
  324. Jul 20 20:01:23 <thearrowflies> whats the next order of business?
  325. Jul 20 20:01:30 <TheDuceCat> not sure
  326. Jul 20 20:01:34 <WolfeL> will there be an updated post w/ all the modifcations you've spoken about? I'm a bit late sorry
  327. Jul 20 20:01:39 <TheDuceCat> yeah
  328. Jul 20 20:01:43 <WolfeL> okay thank you
  329. Jul 20 20:01:47 <TheDuceCat> git behaviour?
  330. Jul 20 20:02:03 <Suner> git behaviour?
  331. Jul 20 20:02:09 <Kobono> rebase vs merge?
  332. Jul 20 20:02:18 <TheDuceCat> rebase is bad for teams i think
  333. Jul 20 20:02:28 <miyako> I'm back
  334. Jul 20 20:02:32 <thearrowflies> i should probably read up on git before i vote for anything
  335. Jul 20 20:02:45 <TheDuceCat> how i did it with a team was have every member fork the repo and pull request new changes in
  336. Jul 20 20:03:05 <miyako> IMHO the proper approach is that if you have a patch you want to submit, you should rebase onto the head of master, fix conflicts, then submit the patch
  337. Jul 20 20:03:11 * centigrade233 has quit (Ping timeout: 245 seconds)
  338. Jul 20 20:03:35 <Kobono> so
  339. Jul 20 20:03:41 <Kobono> git pull --rebase
  340. Jul 20 20:03:48 <Kobono> work out the conflicts
  341. Jul 20 20:03:51 <Kobono> git add them
  342. Jul 20 20:03:55 <Kobono> fit commit again
  343. Jul 20 20:04:00 <Kobono> then git push
  344. Jul 20 20:04:01 <Kobono> ?
  345. Jul 20 20:04:08 <Suner> I don't have much experience with git, but isn't pull the answer to patches?
  346. Jul 20 20:04:46 <Kobono> git pull fetches the remote repo and tries to merge it with your local version
  347. Jul 20 20:04:53 <Kobono> and warns you about conflicts
  348. Jul 20 20:04:53 <miyako> Suner: you can still use pull instead of sending a diff, I'm just considering a pull request to be a patch
  349. Jul 20 20:05:02 <TheDuceCat> you can request a pull from the main repo
  350. Jul 20 20:05:10 <TheDuceCat> and people can comment on the patch etc.
  351. Jul 20 20:05:18 <TheDuceCat> and an admin can accept it
  352. Jul 20 20:05:29 <Suner> ah okay, that's what I thought
  353. Jul 20 20:05:48 <TheDuceCat> it works well
  354. Jul 20 20:06:21 <Suner> well git has become a real popular guy these days, so I'd hope as much :)
  355. Jul 20 20:06:27 <miyako> I like the kernel's method of having a merge window
  356. Jul 20 20:06:48 <miyako> so like once a month we have a 1 or 2 week merge window, where people who have patches ready can submit pull requests
  357. Jul 20 20:06:56 <chancez> tbh you should rebase for any related commits
  358. Jul 20 20:07:08 <miyako> then have the following month for people to do their development
  359. Jul 20 20:07:12 <chancez> rebasing within your own commits
  360. Jul 20 20:07:44 <TheDuceCat> remember to make small commits
  361. Jul 20 20:07:48 <TheDuceCat> that focus on one task
  362. Jul 20 20:08:10 <chancez> each task should be composed of a few commits, and when finished you should rebase to smash it all into 1 commit to merge in
  363. Jul 20 20:08:36 <chancez> otherwise your git repo is going to be very disorganized and have a lot of wasted commit messages and logs to read through
  364. Jul 20 20:08:50 <miyako> chancez: +1
  365. Jul 20 20:08:52 <chancez> also merging once a month with small group projects like this usually ends up bad
  366. Jul 20 20:08:57 <TheDuceCat> pull requests can consist of multiple commits
  367. Jul 20 20:09:09 <Suner> yeah once a month? too long.
  368. Jul 20 20:09:11 <TheDuceCat> so you don't have to combine them
  369. Jul 20 20:09:20 <chancez> if you dont have people merging in their changes frequently enough, things deviate, and no checks and balances come into play
  370. Jul 20 20:09:25 <TheDuceCat> once a week/two weeks
  371. Jul 20 20:09:40 <miyako> Maybe have a merge window of "weekends" ?
  372. Jul 20 20:09:46 <TheDuceCat> ^ could work
  373. Jul 20 20:09:51 * calzone21 has quit (Ping timeout: 245 seconds)
  374. Jul 20 20:10:08 <chancez> also, you should probably give time for others to comment or correct pull requests
  375. Jul 20 20:10:23 <chancez> like submit a pull request, well someone has to look over it and make sure its up to par
  376. Jul 20 20:10:33 <chancez> and refuse it if the patch isnt going to be what you want
  377. Jul 20 20:10:41 <TheDuceCat> https://help.github.com/articles/using-pull-requests/
  378. Jul 20 20:10:44 <ArrowBot> Title: Using Pull Requests · github:help (at help.github.com)
  379. Jul 20 20:10:47 * calzone21 (ae5811cf@gateway/web/freenode/ip.174.88.17.207) has joined #rpcdesktop
  380. Jul 20 20:11:11 <miyako> what I'm sort of hoping the eventual workflow will be is that people pull the latest changes at the end of every merge window (say every monday morning or whatever)
  381. Jul 20 20:11:20 <TheDuceCat> https://github.com/jquery/jquery/pull/865
  382. Jul 20 20:11:22 <ArrowBot> Title: Pull Request #865: For 1.8: fixes #12088, Webkit now returning percentages for more getComputedStyle properties by mikesherov · jquery/jquery · GitHub (at github.com)
  383. Jul 20 20:11:23 <miyako> then work on their code, talking about it here, having people look over what they are doing, etc.
  384. Jul 20 20:11:26 <calzone21> alright guys, i have to go. take care !
  385. Jul 20 20:11:29 * calzone21 has quit (Client Quit)
  386. Jul 20 20:11:30 <TheDuceCat> see ya
  387. Jul 20 20:11:43 <miyako> then on fridays they submit pull requests for the things that they want pulled, and we work on that over the weekend
  388. Jul 20 20:11:55 <miyako> also discussing things here, e.g. why to pull or not pull, etc.
  389. Jul 20 20:13:14 <chancez> I feel like I should say this, for people who aren't aware of how to use git.
  390. Jul 20 20:13:16 <chancez> But
  391. Jul 20 20:13:24 <chancez> Branch early, and branch often
  392. Jul 20 20:14:00 <chancez> git branches let you work on an individual task, and revert to the original code you had for other tasks as well, all at the same time, without needing multiple copies of the repo
  393. Jul 20 20:14:01 <Kobono> yeah, branches are cheap in git
  394. Jul 20 20:14:09 <chancez> each branch should be 1 task
  395. Jul 20 20:14:19 <chancez> and usually each branch is going to be 1 merge
  396. Jul 20 20:15:02 <paise> Say for example I want to implement a small feature which would take say 2-3 weeks, so I create a branch. Now should I rebase it with master or merge it?
  397. Jul 20 20:15:42 <chancez> neither
  398. Jul 20 20:15:44 <chancez> well
  399. Jul 20 20:16:22 <chancez> you usually create the branch, make it work, pull request for that branch, upstream will merge it, now you pull down and merge upstream with your master branch
  400. Jul 20 20:16:34 <chancez> dont rebase it...that would break things
  401. Jul 20 20:16:45 <chancez> you use rebase when you are doing something like this
  402. Jul 20 20:17:04 <chancez> edit code, commit some, edit again, commit again, edit more, final commit #3
  403. Jul 20 20:17:12 <chancez> now you want to squash that all into 1 commit
  404. Jul 20 20:17:20 <chancez> rebase commit#1 commit#3
  405. Jul 20 20:17:32 <chancez> and now its 1 single easy to merge in request
  406. Jul 20 20:18:00 <chancez> if your intial commit is based off of something thats behind the master branch though, dont rebase, it will break things
  407. Jul 20 20:18:31 <paise> Ok so even if it would take a few week sto get a feature implemented, the idea is to keep submitting whatver we have every week and pull in the master.
  408. Jul 20 20:18:43 <chancez> well only if its working
  409. Jul 20 20:19:01 <chancez> and hopefully your not working on a task that is literally 1 task that takes 2-3 weeks
  410. Jul 20 20:19:05 <miyako> paise: the idea is that every week the things that are complete will be merged, but you only submit a pull request if you have a feature that is done
  411. Jul 20 20:19:15 * centigrade233 (60f24712@gateway/web/freenode/ip.96.242.71.18) has joined #rpcdesktop
  412. Jul 20 20:19:24 <paise> Alright, got it.
  413. Jul 20 20:19:31 <chancez> programming should be broken into very small pieces, so hopefully each item you work on should be 1 of those items that can be merged in each week
  414. Jul 20 20:20:16 <miyako> I would expect that, as we go on, the length of time for features will increase, because there might be more tricky algorithmic work, or work that needs to touch more pieces of code
  415. Jul 20 20:20:16 <Suner> I've never known git was so useful
  416. Jul 20 20:20:20 * bimo (54c2cb93@gateway/web/freenode/ip.84.194.203.147) has joined #rpcdesktop
  417. Jul 20 20:20:29 <bimo> oi
  418. Jul 20 20:20:29 <miyako> but it's also going to depend a lot on how much time you have to dedicate to the project
  419. Jul 20 20:20:48 <miyako> if you only have a few hours each weekend to work, then it might take you a few merge windows to get a feature done
  420. Jul 20 20:20:52 <TheDuceCat> how's this? http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
  421. Jul 20 20:20:54 <ArrowBot> (10/0)[0] "A Git Workflow for Agile Teams" http://www.reddit.com/r/git/comments/8mw7y/
  422. Jul 20 20:20:55 <ArrowBot> <http://ln-s.net/3M:u> (at reinh.com)
  423. Jul 20 20:21:52 <miyako> TheDuceCat: that's good, except for merging in with master and pushing to the main repo will be done by submitting pull requests
  424. Jul 20 20:22:01 <TheDuceCat> yeah
  425. Jul 20 20:22:14 <miyako> rebasing might be done by the maintainers instead of the people submitting requests as well
  426. Jul 20 20:23:10 <chancez> miyako: that sounds smart..
  427. Jul 20 20:23:11 <TheDuceCat> yeah as i said pull requests can consist of multiple commits
  428. Jul 20 20:23:19 <centigrade233> back
  429. Jul 20 20:23:20 <chancez> id hate someone to fuck up their shit
  430. Jul 20 20:24:16 <centigrade233> what are we talking about now?
  431. Jul 20 20:25:13 <miyako> I think we need to talk about requirements, and also about getting the first bits of code written
  432. Jul 20 20:26:00 <Suner> ^
  433. Jul 20 20:26:20 <Suner> do we even have a repo setup yet?
  434. Jul 20 20:26:27 <TheDuceCat> yeah
  435. Jul 20 20:26:31 <Suner> link?
  436. Jul 20 20:26:32 <WolfeL> Have established a solid understanding of what it is the program is going to be/how it will function?
  437. Jul 20 20:26:48 <WolfeL> have we*
  438. Jul 20 20:26:53 <Kobono> not yet
  439. Jul 20 20:27:03 <miyako> Suner: https://github.com/RPCDesktop/tiledr
  440. Jul 20 20:27:05 <ArrowBot> Title: RPCDesktop/tiledr · GitHub (at github.com)
  441. Jul 20 20:27:06 <thearrowflies> we discussed it at the last meeting
  442. Jul 20 20:27:25 <miyako> the treloo board has a few things listed
  443. Jul 20 20:27:29 <miyako> *trello
  444. Jul 20 20:27:31 <paise> miyako: requirements as in features?
  445. Jul 20 20:27:35 <WolfeL> I've read through and understand the basic Ideas of it, I just didn't know if it was expanded upon
  446. Jul 20 20:27:38 <thearrowflies> something went wrong with the license?
  447. Jul 20 20:27:41 <miyako> paise: yeah
  448. Jul 20 20:27:43 <TheWalkingDerp> trello?
  449. Jul 20 20:27:47 <WolfeL> I've been following the trello yes, thank you
  450. Jul 20 20:28:28 <paise> Ok, so is ther going to be tile creator, if so, should that be on high priority?
  451. Jul 20 20:28:30 <miyako> thearrowflies: the only commit was a license file I added; we agreed on GPL3 so I added the GPL license to the repo
  452. Jul 20 20:29:08 <thearrowflies> yeah, but the "something went wrong" wasnt there when you added it
  453. Jul 20 20:29:36 <thearrowflies> ah now its gone
  454. Jul 20 20:29:37 <miyako> thearrowflies: I don't see the "something went wrong"?
  455. Jul 20 20:29:42 <miyako> maybe a github bug?
  456. Jul 20 20:29:45 <thearrowflies> probably
  457. Jul 20 20:30:17 <miyako> so yeah, I think on the fronted the biggest things to start with are the GUI main window itself, an OpenGL context to display the map, and maybe a tile browser
  458. Jul 20 20:30:29 <TheDuceCat> yep
  459. Jul 20 20:30:37 <TheDuceCat> we need some mockups
  460. Jul 20 20:30:42 <thearrowflies> shit
  461. Jul 20 20:30:45 <miyako> on the backend we probably need to work on defining the APIs for getting a mesh of the map, placing tiles, and defining some sort of file formats
  462. Jul 20 20:30:45 <thearrowflies> i said i was giong to do those
  463. Jul 20 20:30:53 <TheDuceCat> k
  464. Jul 20 20:31:22 <thearrowflies> i have an idea in mine
  465. Jul 20 20:31:25 <chancez> recently ive gotten interested in the python area
  466. Jul 20 20:31:27 <thearrowflies> but ill have to shop it first
  467. Jul 20 20:31:31 <chancez> if you guys have any need for that.
  468. Jul 20 20:31:34 <TheDuceCat> we do
  469. Jul 20 20:31:50 <TheDuceCat> the program is going to be barebones
  470. Jul 20 20:31:54 <TheDuceCat> it's going to ship with default plugins
  471. Jul 20 20:31:54 <chancez> i know, but its a matter of when, since your developing your own api
  472. Jul 20 20:32:53 <miyako> I'm thinking for the tiles themselves the backend API will have some sort of function that will give you a tile struct that has probably a tile name as a string and a data pointer to a 32x32 bitmap with a thumbnail image
  473. Jul 20 20:33:16 <Suner> which build tool will we be using?
  474. Jul 20 20:33:25 <miyako> Suner: good question :)
  475. Jul 20 20:33:26 <paise> Cmake?
  476. Jul 20 20:33:27 <miyako> CMake?
  477. Jul 20 20:33:33 <Suner> SCons?
  478. Jul 20 20:34:26 <miyako> vote on build system: autotools, cmake, scons ?
  479. Jul 20 20:34:29 <TheDuceCat> i'm sort of new to build tools so idk
  480. Jul 20 20:34:38 <Suner> I vote against autotools
  481. Jul 20 20:34:38 <TheDuceCat> i'll leave it up to you guys
  482. Jul 20 20:34:39 <Kobono> TheDuceCat: same
  483. Jul 20 20:34:41 <miyako> I know autotools and cmake well, I don't know scons at all
  484. Jul 20 20:34:47 <paise> against autotools
  485. Jul 20 20:34:55 <miyako> I vote for cmake because I know it, and it's not autotools
  486. Jul 20 20:34:55 <TheDuceCat> can we have a feature comparison?
  487. Jul 20 20:35:36 <miyako> TheDuceCat: I don't know that there is an appreciable feature difference, more of a question of how much the tool makes you want to stab yourself in the face
  488. Jul 20 20:35:45 <TheDuceCat> k
  489. Jul 20 20:35:48 <Suner> http://www.scons.org/wiki/SconsVsOtherBuildTools
  490. Jul 20 20:35:48 <miyako> which for autotools is infinity, it makes you want to stab yourself in the face in an amount of infinity
  491. Jul 20 20:35:57 <ArrowBot> <http://ln-s.net/$Uay> (at www.scons.org)
  492. Jul 20 20:35:58 * Accipiter (~Accipiter@96.18.31.36) has joined #rpcdesktop
  493. Jul 20 20:36:20 <FRodrigues> what's the problem of using auto-tools?
  494. Jul 20 20:36:29 <Suner> to be clear: I have no experience with SConds
  495. Jul 20 20:37:04 <miyako> CMake has a support in many IDEs, and it's pretty easy to build debian packages when you're using cmake if that's a concern
  496. Jul 20 20:37:23 <Suner> only build tool I have experience is Jam, and I'm sure no one here wants to use that
  497. Jul 20 20:37:26 <paise> I vote for CMake because I have worked with it, and it is a breeze to work with Qt and QtCreator.
  498. Jul 20 20:38:25 <thearrowflies> I thought Qt required QMake
  499. Jul 20 20:38:34 <Suner> ^
  500. Jul 20 20:38:40 <chancez> it does
  501. Jul 20 20:38:46 <chancez> its got its own build system
  502. Jul 20 20:38:50 <paise> Yes, it is the default build syste, but CMake is more feature rich.
  503. Jul 20 20:38:54 <chancez> which generates make
  504. Jul 20 20:39:16 <Suner> I'm fine with cmake
  505. Jul 20 20:39:24 <Suner> even though it doesn't work with me on windows
  506. Jul 20 20:39:26 * centigrade233 has quit (Ping timeout: 245 seconds)
  507. Jul 20 20:39:51 <thearrowflies> cmake doesnt work on windows? >.>
  508. Jul 20 20:39:56 <Suner> it does
  509. Jul 20 20:39:56 <chancez> Suner: dont use windows obviously!
  510. Jul 20 20:39:57 <TheDuceCat> it does
  511. Jul 20 20:39:58 <Suner> just not for me
  512. Jul 20 20:39:59 <miyako> it's supposed to work on windows
  513. Jul 20 20:40:10 <TheDuceCat> it's worked for me
  514. Jul 20 20:40:14 <Suner> every time I try to generate a VS solution
  515. Jul 20 20:40:15 <paise> Also I have experience in building a gnu package using CMake on windows, It is not that much of a hassle.
  516. Jul 20 20:40:17 <Suner> it just craps out
  517. Jul 20 20:40:33 <Suner> but I'll be switching back to fedora soon~
  518. Jul 20 20:40:37 <paise> thearrowflies: it works.
  519. Jul 20 20:40:54 <Suner> and trying out the whole
  520. Jul 20 20:40:55 <chancez> Suner: fedora++ <3
  521. Jul 20 20:40:57 <Suner> vim stuff
  522. Jul 20 20:41:03 <chancez> vim ++++++
  523. Jul 20 20:41:37 <Suner> so it's settled then? CMake it is?
  524. Jul 20 20:41:41 <chancez> i praise vim a lot, mainly because when i go to my CS classes and people dont know how a compiler works w/o visual studio..i die inside.
  525. Jul 20 20:41:43 <TheDuceCat> +1
  526. Jul 20 20:41:52 <Kobono> +1
  527. Jul 20 20:41:57 <miyako> cmake +1
  528. Jul 20 20:42:02 <miyako> vim +100
  529. Jul 20 20:42:11 <WolfeL> I should get vim then I guess
  530. Jul 20 20:42:16 <Suner> chancez: lol, people in my classes still don't know how to use the debugger in visual studio
  531. Jul 20 20:42:16 <WolfeL> all this habub
  532. Jul 20 20:42:25 <chancez> (php)-- * 100
  533. Jul 20 20:42:34 <chancez> Suner: yeah same
  534. Jul 20 20:42:38 <Suner> they don't even know what a command line is....
  535. Jul 20 20:42:41 <chancez> no one in any of my classes knows what valgrind is
  536. Jul 20 20:42:42 * centigrade233 (60f24712@gateway/web/freenode/ip.96.242.71.18) has joined #rpcdesktop
  537. Jul 20 20:42:46 <chancez> im just like stumped
  538. Jul 20 20:43:16 <WolfeL> what are the advantages to using vim over using something simple like gedit?
  539. Jul 20 20:43:26 <chancez> gedit is terrible, vim isnt
  540. Jul 20 20:43:41 <WolfeL> :'(
  541. Jul 20 20:43:42 <FRodrigues> cmake++
  542. Jul 20 20:43:45 <Accipiter> http://yannesposito.com/Scratch/en/blog/Learn-Vim-Progressively/
  543. Jul 20 20:43:46 <ArrowBot> (1007/312)[368] "Learn Vim Progressively" http://www.reddit.com/r/programming/comments/jxusk/
  544. Jul 20 20:43:49 * Suner has quit (Read error: Connection reset by peer)
  545. Jul 20 20:43:50 <Accipiter> that helped me learn vim
  546. Jul 20 20:44:03 <chancez> vim is extensible, is highly supported, runs in the terminal (over ssh), and has vim movement
  547. Jul 20 20:44:05 <WolfeL> bookmarked
  548. Jul 20 20:44:14 <Accipiter> vim is awesome
  549. Jul 20 20:44:14 <TheDuceCat> does it matter what editor we use?
  550. Jul 20 20:44:19 <chancez> Accipiter++
  551. Jul 20 20:44:27 <miyako> TheDuceCat: not really
  552. Jul 20 20:44:35 * Suner (~Sun@unaffiliated/suner) has joined #rpcdesktop
  553. Jul 20 20:44:36 <TheDuceCat> i like sublime text myself
  554. Jul 20 20:44:40 <Suner> that was weird
  555. Jul 20 20:44:41 <paise> No I guess, as long as we keep in mind about line endings
  556. Jul 20 20:44:50 <TheWalkingDerp> the last time i used vim, i couldn't figure out how to exit >.>
  557. Jul 20 20:44:56 <thearrowflies> line endings?
  558. Jul 20 20:44:56 <Suner> ^
  559. Jul 20 20:44:58 <FRodrigues> xD
  560. Jul 20 20:45:01 <chancez> I feel like most people have that problem
  561. Jul 20 20:45:03 <chancez> except
  562. Jul 20 20:45:05 <Accipiter> I used sublime text, its way prettier
  563. Jul 20 20:45:06 <FRodrigues> i use gedit
  564. Jul 20 20:45:07 <FRodrigues> xD
  565. Jul 20 20:45:09 <chancez> the first thing on the vim page is :help
  566. Jul 20 20:45:09 <miyako> paise: good point; unix line endings for everything?
  567. Jul 20 20:45:11 <chancez> and then
  568. Jul 20 20:45:15 <Accipiter> but vim is more powerful
  569. Jul 20 20:45:16 <paise> Of course
  570. Jul 20 20:45:17 <chancez> people should use google
  571. Jul 20 20:45:21 <chancez> if they cant figure it out
  572. Jul 20 20:45:23 <chancez> itslike
  573. Jul 20 20:45:25 <chancez> RTFM
  574. Jul 20 20:45:28 <Suner> lol
  575. Jul 20 20:45:29 <Suner> yeah...
  576. Jul 20 20:45:32 <miyako> vimtutor ftw
  577. Jul 20 20:45:38 <Suner> I remember setting up archlinux once
  578. Jul 20 20:45:38 <Accipiter> ^
  579. Jul 20 20:45:39 <chancez> miyako: yep.
  580. Jul 20 20:45:40 <Suner> opened vim
  581. Jul 20 20:45:43 <Suner> couldn't get out
  582. Jul 20 20:45:44 <Suner> lol'd
  583. Jul 20 20:45:46 <chancez> fail.
  584. Jul 20 20:45:47 <Accipiter> lol
  585. Jul 20 20:45:50 <chancez> archlinux++
  586. Jul 20 20:45:58 <chancez> i used arch as a server for 2 months
  587. Jul 20 20:46:00 <chancez> yep
  588. Jul 20 20:46:02 <chancez> not doing that again
  589. Jul 20 20:46:12 <chancez> laptop distro? sure. server? NOPE
  590. Jul 20 20:46:15 <miyako> I like arch a lot for a desktop system
  591. Jul 20 20:46:24 <Suner> yeah,
  592. Jul 20 20:46:46 <Suner> but I like fedora more, less work for lazy me
  593. Jul 20 20:46:47 <chancez> anyways
  594. Jul 20 20:46:53 <chancez> i took away from your meeting discussion
  595. Jul 20 20:46:56 <chancez> should get back on track
  596. Jul 20 20:47:02 <chancez> at least until later ;)
  597. Jul 20 20:47:05 <miyako> so we were talking about requirements
  598. Jul 20 20:47:22 <miyako> and I think we agreed that on the frontend we need mockups and to get the basic main windows, opengl context, and a tile browser in place
  599. Jul 20 20:47:38 <miyako> on the backend we need to define some APIs and data structures so the GUI will have an idea of how to talk to us
  600. Jul 20 20:47:59 <paise> I think there would be two main modes, a tile drawing mode and a map drawing mode using the tilesets created?
  601. Jul 20 20:48:16 <Suner> I
  602. Jul 20 20:48:21 <Accipiter> A tile editing mode would actually be awesome
  603. Jul 20 20:48:46 <Accipiter> I think artists would love not having to switch programs
  604. Jul 20 20:48:57 <Suner> don't believe in defining APIs before writing code, they're pretty much guaranteed to cange
  605. Jul 20 20:48:58 <miyako> I think a tile editing mode would be too much work at first
  606. Jul 20 20:49:13 <thearrowflies> ^
  607. Jul 20 20:49:24 <TheDuceCat> ^
  608. Jul 20 20:49:26 <Kobono> miyako: agreed
  609. Jul 20 20:49:31 <Accipiter> Probably
  610. Jul 20 20:49:35 <paise> Yes
  611. Jul 20 20:49:38 <chancez> Suner: yes.
  612. Jul 20 20:49:41 <Accipiter> But we should keep it in mind
  613. Jul 20 20:49:43 <miyako> Suner: change is inevitable, but I think that defining APIs up front is a good way of communicating general ideas
  614. Jul 20 20:49:43 <Kobono> just use specialised spftware for that
  615. Jul 20 20:50:09 <miyako> a tile composer might not be a bad idea, if we want to have tiles that consist of a background image + sprites
  616. Jul 20 20:50:25 <TheDuceCat> tile editor is good plugin idea
  617. Jul 20 20:50:32 <TheDuceCat> that can really test the plugin framework
  618. Jul 20 20:50:37 <miyako> TheDuceCat: agreed
  619. Jul 20 20:50:38 <Accipiter> yeah
  620. Jul 20 20:51:50 <chancez> are you guys going to be using any libraries other than Qt?
  621. Jul 20 20:52:53 <miyako> on the backend we'll probably be using a few; I imagine on the frontend OpenGL in addition to qt at least
  622. Jul 20 20:53:17 <paise> I have no experience creating tile maps, but is there some way to set properties on tiles when laying out on map. For example, set a tile as Pass through/opaque?
  623. Jul 20 20:53:32 <TheDuceCat> different layers
  624. Jul 20 20:53:37 <TheDuceCat> object layers etc...
  625. Jul 20 20:53:45 <paise> I guess it is done on a game engine rather than a tile editor?
  626. Jul 20 20:53:50 <Kobono> or just add properties to the tile struct
  627. Jul 20 20:53:55 <TheDuceCat> you can put the data on the tile
  628. Jul 20 20:53:59 <TheDuceCat> or have a collision layer
  629. Jul 20 20:54:04 <paise> BTW are we using xml files for the maps generated?
  630. Jul 20 20:54:07 <TheDuceCat> specifically for tiles that are non pass thorugh
  631. Jul 20 20:54:13 <TheDuceCat> not decided
  632. Jul 20 20:54:15 <TheDuceCat> maybe json
  633. Jul 20 20:54:24 <TheDuceCat> we want to make it easy on the game developer
  634. Jul 20 20:54:27 <miyako> paise: we haven't decided yet, xml, json, and binary data have all been thrown about
  635. Jul 20 20:54:43 <Suner> I would say binary
  636. Jul 20 20:55:16 * centigrade233 has quit (Ping timeout: 245 seconds)
  637. Jul 20 20:55:21 <Kobono> I wouldn't
  638. Jul 20 20:55:41 <Suner> I just can't see any possible reason to use xml/json
  639. Jul 20 20:55:42 <paise> Isn't the map basically a set of tiles ids and coordinates? If so xml or json seems reasonable.
  640. Jul 20 20:55:51 <TheDuceCat> yeah ^
  641. Jul 20 20:55:55 <Accipiter> could someone quickly explain to me how binary data would work in this situation? I have only ever seen xml used for tilemaps (although I can see how json could do it)
  642. Jul 20 20:55:58 <Suner> the primary benefit of xml/json is make it easy for a human to modify
  643. Jul 20 20:56:08 <paise> Game dev would be using the xml/json and the tileset to creae his games
  644. Jul 20 20:56:14 <Suner> I can't see anyone going to edit a tilemap by hand
  645. Jul 20 20:56:18 <Suner> in xml
  646. Jul 20 20:56:24 <TheDuceCat> it's easy to parse
  647. Jul 20 20:56:28 <miyako> paise: you also need the image data, and possibly mesh data for the terrain if the map isn't flat
  648. Jul 20 20:56:28 <Suner> binary is easier
  649. Jul 20 20:56:50 <Suner> binary is the easist to parse, you don't need any libraries to do it
  650. Jul 20 20:56:56 <TheDuceCat> i guess
  651. Jul 20 20:56:57 <paise> miyako: He would use the tileset + xml?
  652. Jul 20 20:57:03 <Suner> and if you need to include the image data in the map?
  653. Jul 20 20:57:09 <TheDuceCat> tiled uses xml
  654. Jul 20 20:57:18 * Bradford has quit (Quit: Leaving)
  655. Jul 20 20:57:32 <miyako> paise: one of the intended features is to do some modification to the images on the tiles, so you can't just load the tile images as is
  656. Jul 20 20:57:58 <paise> Oh, ok I understand now. Alright.
  657. Jul 20 20:59:01 <TheDuceCat> tiled uses xml so why isn't it practical for us?
  658. Jul 20 20:59:07 <TheDuceCat> i still don't fully understand
  659. Jul 20 20:59:34 <Kobono> I'm signing off, it's getting quite late. Goodbye everyone.
  660. Jul 20 20:59:57 * Kobono has quit (Quit: Page closed)
  661. Jul 20 21:00:15 <miyako> TheDuceCat: XML is practical, but it might not be as easy to deal with as binary, I'm not opposed to either
  662. Jul 20 21:00:24 <TheDuceCat> alright
  663. Jul 20 21:00:31 <miyako> one of the features that we'll have that tiled doesn't though is the ability to actually modify the image data on the tiles
  664. Jul 20 21:00:49 <miyako> so unlike tiled, we can't just load in the tile images every time, we have to somehow store the modified image data
  665. Jul 20 21:00:59 <miyako> so if we used XML we'd need to include the binary image data in there
  666. Jul 20 21:01:05 <TheDuceCat> alright
  667. Jul 20 21:02:08 <miyako> my personal preference would be to default to a native binary format, with a feature that could be added later to export to XML
  668. Jul 20 21:02:29 <miyako> it would be a good feature to add using the python plugin api IMHO
  669. Jul 20 21:02:30 <TheDuceCat> ok
  670. Jul 20 21:02:59 <Accipiter> That sounds like a good idea, then the user can decide for themselves.
  671. Jul 20 21:04:05 <TheDuceCat> what do you mean by modifying image data
  672. Jul 20 21:04:46 <miyako> one feature I'd like to do (open to voting by everyone of course) is to generate tile image data dynamically; an example would be to blend textures together at the seams so that you don't have obvious tiling
  673. Jul 20 21:05:07 <miyako> another example would be to generate synthetic textures based on a seed image for covering a large area with a given tile
  674. Jul 20 21:05:28 <TheDuceCat> makes sense yeah
  675. Jul 20 21:05:50 <Accipiter> I like it, but it seems like it would be very difficult to implement.
  676. Jul 20 21:05:50 <miyako> also, deforming images to fit terrain, and baking in lighting could be done in the future as we start to add more game-oriented features
  677. Jul 20 21:06:25 <TheDuceCat> yeah hopefully can be made with plugins
  678. Jul 20 21:06:36 <miyako> Accipiter: honestly, I'm throwing those features in there because computer graphics, etc. is my area of interest so it's something I'd like to do
  679. Jul 20 21:07:13 * centigrade233 (60f24712@gateway/web/freenode/ip.96.242.71.18) has joined #rpcdesktop
  680. Jul 20 21:07:34 <Accipiter> OK thats what this project is for. I would love to learn about computer graphics
  681. Jul 20 21:07:44 <Accipiter> And it sounds like a killer feature
  682. Jul 20 21:07:55 <Suner> << also
  683. Jul 20 21:09:05 <centigrade233> what's the killer feature?
  684. Jul 20 21:09:44 <Suner> <miyako> one feature I'd like to do (open to voting by everyone of course) is to generate tile image data dynamically; an example would be to blend textures together at the seams so that you don't have obvious tiling
  685. Jul 20 21:10:11 <Suner> this meeting has been going on pretty long
  686. Jul 20 21:10:14 <Accipiter> <miyako> another example would be to generate synthetic textures based on a seed image for covering a large area with a given tile
  687. Jul 20 21:11:18 <Suner> I'd like to finish up on the basic requirements
  688. Jul 20 21:14:26 <miyako> I agree, I think we should has out the features we'd like to have implemented in the next month or so; so that people can start writing code
  689. Jul 20 21:17:56 <TheDuceCat> so feature discussion?
  690. Jul 20 21:18:03 <paise> Say for example 0.1 version lets us use some tiles from a tile browser on the left and allows us to lay it on a specific sized map on the right? I think keeping the first versions pretty basic would get the project going, especially newcomers could get comfortable.
  691. Jul 20 21:18:14 <TheDuceCat> yep
  692. Jul 20 21:18:30 * TheDuceCat has changed the topic to: Initial Feature Discussion
  693. Jul 20 21:18:39 <miyako> paise: that sounds like a good goal to me; should we assume that the map is flat for now
  694. Jul 20 21:18:50 <Suner> yes
  695. Jul 20 21:18:51 <miyako> so the GUI just needs to get x/y coordinates
  696. Jul 20 21:18:51 <TheDuceCat> maybe layers after that?
  697. Jul 20 21:19:03 <paise> yes
  698. Jul 20 21:19:24 <miyako> so I'm thinking basically the user selects a tile, and then clicks a tile on the map, and the GUI sends to the backend something like add_tile(tile_id, x, y)
  699. Jul 20 21:19:37 <TheDuceCat> yep
  700. Jul 20 21:19:43 <miyako> (0,0) for the top left tile
  701. Jul 20 21:19:47 <TheDuceCat> yeah
  702. Jul 20 21:19:50 <TheDuceCat> +x right
  703. Jul 20 21:19:51 <TheDuceCat> +y down
  704. Jul 20 21:19:52 <paise> yes
  705. Jul 20 21:19:55 <miyako> yep
  706. Jul 20 21:20:20 <Accipiter> So how would the backend know what tile is what tile id? Would it go through the tilesheet when the user loads one?
  707. Jul 20 21:20:33 <Suner> gui has to tell it
  708. Jul 20 21:20:44 <TheDuceCat> yeah
  709. Jul 20 21:20:45 <TheDuceCat> like
  710. Jul 20 21:20:50 <TheDuceCat> setSelectedTile(tiletype)
  711. Jul 20 21:20:57 <TheDuceCat> something of that nature
  712. Jul 20 21:21:02 <Accipiter> OK
  713. Jul 20 21:21:07 <miyako> does it, or does the backend load the tiles
  714. Jul 20 21:21:23 <miyako> and then the gui does something like getTileDict(tileDirectory)
  715. Jul 20 21:21:30 <TheDuceCat> backend can load it
  716. Jul 20 21:21:36 <TheDuceCat> but if you click on it backend has to know what tile it is
  717. Jul 20 21:21:38 <Suner> btw, sorry to go off topic here, but what is the point of having a backend again?
  718. Jul 20 21:21:41 <miyako> and is returned a map of some sort, with tileID -> tile data
  719. Jul 20 21:21:49 <TheDuceCat> miyako take this
  720. Jul 20 21:22:14 <TheWalkingDerp> the backend is where the functionality is?
  721. Jul 20 21:22:19 <miyako> Suner: there are a couple of reasons: one is we wanted to be able to have multiple interfaces, and having the backend be a library makes that easier; using C makes it easier to create language bindings
  722. Jul 20 21:22:20 <TheDuceCat> yeah
  723. Jul 20 21:22:20 <TheWalkingDerp> so the gui just exposes it
  724. Jul 20 21:22:38 <TheDuceCat> so python can access it
  725. Jul 20 21:23:22 <Accipiter> So you do something like make_tileset(tiles, x, y) and the backend would map tileID -> tile_data?
  726. Jul 20 21:23:34 <Accipiter> x y being the size of the tiles
  727. Jul 20 21:23:49 <Suner> miyako: okay, but when would you need another language to interface with the backend?
  728. Jul 20 21:24:18 <TheDuceCat> c++ for gui
  729. Jul 20 21:24:24 <miyako> Suner: as an example, say you wanted to make a native Cocoa application on OSX, you could use the backend and write a gui in objective c
  730. Jul 20 21:24:24 <TheDuceCat> python for plugins
  731. Jul 20 21:24:48 <miyako> or if you wanted to make a web tool for making makes, you could have a python program that loads the backend, and exposes web services to a javascript ui
  732. Jul 20 21:26:00 <Suner> ah
  733. Jul 20 21:26:09 <Suner> but you could have very well used C++ and write a C interface
  734. Jul 20 21:26:42 <TheDuceCat> not nessecarily
  735. Jul 20 21:26:47 <miyako> Suner: it's often easier to have bindings to multiple languages when you use C, and it also gives people who want to learn C an area of the project to work on
  736. Jul 20 21:26:47 <TheDuceCat> wait
  737. Jul 20 21:26:55 <TheDuceCat> ^
  738. Jul 20 21:27:26 <miyako> some of our choices are done for social, as well as technical reasons :)
  739. Jul 20 21:27:40 <Suner> okay, I was just wondering why we chose to use 3 different languages
  740. Jul 20 21:27:50 <TheDuceCat> different interests
  741. Jul 20 21:28:27 <Suner> (I've never done desktop work in C, so it comes to me as a little weird)
  742. Jul 20 21:30:21 <TheDuceCat> alright we moving on or continue with feature discussion?
  743. Jul 20 21:30:30 <Suner> yes
  744. Jul 20 21:30:41 <Suner> so for starters we need a basic 2d mapping?
  745. Jul 20 21:31:16 <TheDuceCat> yep
  746. Jul 20 21:31:19 <Suner> will we be having a static tile size for a map? or perhaps a dynamic one?
  747. Jul 20 21:31:24 <TheDuceCat> dynamic
  748. Jul 20 21:31:35 <TheDuceCat> what do you mean actually
  749. Jul 20 21:32:04 <centigrade233> scale-able tiles?
  750. Jul 20 21:32:09 <miyako> I think tiles themselves should, at first, just be say 64x64 square images, and the map can be any size of tiles
  751. Jul 20 21:32:13 <Suner> for example, a map sets the size of a tile, so every tile on that map is that size (this makes it easier when placing tiles, x-y)
  752. Jul 20 21:32:15 <TheDuceCat> yeah
  753. Jul 20 21:32:20 <TheDuceCat> they can set what size tiles they want
  754. Jul 20 21:32:29 <TheDuceCat> and map width/height
  755. Jul 20 21:32:35 <Suner> versus dynamic, were tiles can be varying sizes
  756. Jul 20 21:32:40 <TheDuceCat> static for now
  757. Jul 20 21:32:41 <Suner> in the same map
  758. Jul 20 21:32:47 <Suner> okay great lol
  759. Jul 20 21:32:49 <Suner> easy for now
  760. Jul 20 21:33:59 <Suner> square tiles? 64x64 like miyako said?
  761. Jul 20 21:34:17 <TheDuceCat> any size
  762. Jul 20 21:34:21 <TheDuceCat> not exculsively 64 64
  763. Jul 20 21:34:24 <Suner> just for starters
  764. Jul 20 21:34:27 <Accipiter> Would it be easier to implement dynamic tiles now or add it later?
  765. Jul 20 21:34:32 <Suner> add later.
  766. Jul 20 21:34:34 <TheDuceCat> later
  767. Jul 20 21:34:37 <Accipiter> Why?
  768. Jul 20 21:34:43 <Suner> it's not that trivial.
  769. Jul 20 21:34:47 <TheDuceCat> it's not really needed atm
  770. Jul 20 21:34:59 <Suner> at this point
  771. Jul 20 21:35:06 <Suner> I'd just like to see us get some working code up
  772. Jul 20 21:35:13 <TheDuceCat> ^ same
  773. Jul 20 21:35:14 <Accipiter> OK makes sense
  774. Jul 20 21:35:35 <Suner> I think morale is much better when there's showable progress
  775. Jul 20 21:35:37 <miyako> yeah, I think as long as we know we want scalable tiles later we won't get ourselves into too much of a hole by focusing on 64x64 for now
  776. Jul 20 21:35:57 <TheDuceCat> you should be able to do it like tiled
  777. Jul 20 21:35:59 <TheDuceCat> by tileset
  778. Jul 20 21:36:26 <Accipiter> Suner: thats true
  779. Jul 20 21:37:51 <Suner> all right
  780. Jul 20 21:38:14 <TheDuceCat> i'm not saying we need dynamic tiles initially just an option for size when you first make your tilemap
  781. Jul 20 21:38:58 <Suner> I would say yes, for 0.1. but I'd like to actually see us get a working map with 64x64 tiles first
  782. Jul 20 21:39:48 <TheDuceCat> it really wouldn't take much time at all to make other tile sizes
  783. Jul 20 21:39:50 <TheDuceCat> just at the beginning
  784. Jul 20 21:39:51 <TheDuceCat> it asks you
  785. Jul 20 21:39:52 <Suner> after that, I can't imagine it being difficult to change scales
  786. Jul 20 21:39:56 <TheDuceCat> tile size and map size
  787. Jul 20 21:41:15 <Suner> sure, ultimately this is an OSS project (it's just a feature I myself aren't likely to do until I can see a map)
  788. Jul 20 21:42:35 <paise> I think we should talk a bit about graphics/artistic side of ourselves. A call for submitting 1) GUI mockups (which is already set on trello board) 2) Creating some example tiles to include with the program. (we can have list on trello and voteout, and then add it to github)
  789. Jul 20 21:43:02 <TheDuceCat> i can do stick figures!
  790. Jul 20 21:43:13 <Suner> I can do colored boxes.
  791. Jul 20 21:43:17 <centigrade233> me too!
  792. Jul 20 21:43:18 <Suner> haha
  793. Jul 20 21:43:20 <thearrowflies> tiles im not so good with
  794. Jul 20 21:43:28 <paise> don't forget our alien!
  795. Jul 20 21:43:29 <thearrowflies> UIs and things with really straight lines i can do
  796. Jul 20 21:43:33 <centigrade233> i can do stick figures ON colored boxes!
  797. Jul 20 21:44:11 <TheDuceCat> NO WAY
  798. Jul 20 21:44:13 <TheDuceCat> TEACH ME
  799. Jul 20 21:44:14 <Suner> okay
  800. Jul 20 21:44:21 <Suner> what about rendering?
  801. Jul 20 21:44:22 <Accipiter> It would be nice to have our own tiles but there are plenty of free ones we could use.
  802. Jul 20 21:44:28 <Suner> is it the backend's job to render the map?
  803. Jul 20 21:44:37 <Accipiter> or just stick tree and colored boxes
  804. Jul 20 21:44:45 <paise> Suner: I guess we are mostly talking about drawing on a tool like Paint.
  805. Jul 20 21:45:57 <Suner> paise: Yes, but I mean is it up to the backend to also produce the rendering of the map, and not just managing it?
  806. Jul 20 21:46:08 <Suner> I don't know, I don't know much about graphics...
  807. Jul 20 21:46:35 <Accipiter> that would be for miyako I think
  808. Jul 20 21:46:39 <paise> yes
  809. Jul 20 21:47:01 <miyako> saw my name, afk for a second
  810. Jul 20 21:47:59 <Suner> here's where I'm a little confused, we know that the gui must render the map, and allow for editing it. now I'm wondering, does the backend somehow render it and then the gui just also manipulates it?
  811. Jul 20 21:48:02 <Suner> or...?
  812. Jul 20 21:48:09 <Suner> does the gui do all the rendering?
  813. Jul 20 21:48:51 <TheDuceCat> it's opengl so i guess front end
  814. Jul 20 21:51:34 <TheDuceCat> should we wrap this up soon?
  815. Jul 20 21:51:46 <thearrowflies> its been 3 hours
  816. Jul 20 21:51:47 <Suner> probably
  817. Jul 20 21:52:00 <TheDuceCat> alrigh
  818. Jul 20 21:52:02 <TheDuceCat> t
  819. Jul 20 21:52:10 <TheDuceCat> so we discussed code conventions initial features
  820. Jul 20 21:52:13 <TheDuceCat> requirements
  821. Jul 20 21:52:25 <Suner> I'd just like to compile together
  822. Jul 20 21:52:31 <Suner> some *immediate* tasks
  823. Jul 20 21:52:34 <Suner> that need to be done
  824. Jul 20 21:52:37 <TheDuceCat> Trello?
  825. Jul 20 21:52:41 <Suner> so we can get the ball rolling between the next meeting
  826. Jul 20 21:52:57 <miyako> I'm back
  827. Jul 20 21:53:08 <TheDuceCat> we're wrapping up the meeting
  828. Jul 20 21:53:47 <miyako> okay; I apologize for not being more available during the meeting tonight.
  829. Jul 20 21:53:58 <TheDuceCat> it's alright
  830. Jul 20 21:54:06 <miyako> Hopefully I'll recover in a few days and be more available to help out
  831. Jul 20 21:54:12 <TheDuceCat> next meet day?
  832. Jul 20 21:54:21 <TheDuceCat> Monday perhaps?
  833. Jul 20 21:54:37 <thearrowflies> !@#$%
  834. Jul 20 21:54:42 <miyako> Monday will work for me I think
Add Comment
Please, Sign In to add comment
Public Pastes
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!