Home liberachat/#haskell: Logs Calendar

Logs: liberachat/#haskell

←Prev  Next→
Page 1 .. 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 .. 18042
— 1,804,107 events total
2021-08-18 02:57:14 <c_wraith> with a number of elements matching the number of things you're selecting, and appropriate types for each element
2021-08-18 02:57:16 <lechner> single column
2021-08-18 02:58:05 <lechner> https://hackage.haskell.org/package/postgresql-simple-0.6.4/docs/Database-PostgreSQL-Simple.html#t:Connection
2021-08-18 02:58:11 <lechner> sorry
2021-08-18 02:58:38 <c_wraith> You probably want the 1-tuple, then. https://hackage.haskell.org/package/postgresql-simple-0.6.4/docs/Database-PostgreSQL-Simple.html#t:Only
2021-08-18 02:59:21 <c_wraith> try mapM_ (putStrLn . fromOnly)
2021-08-18 02:59:32 <Axman6> yeah I was going to say, Only will be the type you need
2021-08-18 02:59:49 <Axman6> so it'll return Only String's
2021-08-18 02:59:53 <lechner> Only or [Only String] ?
2021-08-18 03:00:09 <c_wraith> r ~ Only String
2021-08-18 03:00:18 <c_wraith> the return type is IO [r]
2021-08-18 03:03:33 ← rubix parts (~user@2601:602:9502:c70:b7f7:ce5b:5e25:126d) (ERC (IRC client for Emacs 28.0.50))
2021-08-18 03:03:47 × lavaman quits (~lavaman@98.38.249.169) (Remote host closed the connection)
2021-08-18 03:04:49 <lechner> it's magic! the calls to fromOnly inside mapM_ were enough to compile
2021-08-18 03:04:59 <c_wraith> the advantage of printing with (mapM_ (putStrLn . fromOnly)) is that type inference means that it uniquely identifies the type of r
2021-08-18 03:05:15 <lechner> yeah, it's amazing!
2021-08-18 03:05:34 <lechner> which way of printin wuold not do so?
2021-08-18 03:05:40 <lechner> printing
2021-08-18 03:05:49 <lechner> would
2021-08-18 03:06:04 <c_wraith> replacing putStrLn with print would leave the type ambiguous
2021-08-18 03:06:24 <c_wraith> or just using (mapM_ print)
2021-08-18 03:06:27 → iqubic joins (~user@2601:602:9502:c70:b7f7:ce5b:5e25:126d)
2021-08-18 03:06:41 <c_wraith> it would *work*, but the types wouldn't be inferred
2021-08-18 03:07:57 × Skyfire quits (~pyon@user/pyon) (Quit: WeeChat 3.2)
2021-08-18 03:08:21 → Skyfire joins (~pyon@user/pyon)
2021-08-18 03:08:53 <lechner> unfortunately the query result is wrong. can -simple pass Pg array types?
2021-08-18 03:09:11 <lechner> the query is otherwise tested
2021-08-18 03:09:17 <lechner> and short
2021-08-18 03:10:24 <c_wraith> looks like it
2021-08-18 03:10:28 <c_wraith> https://hackage.haskell.org/package/postgresql-simple-0.6.4/docs/Database-PostgreSQL-Simple-Types.html#t:PGArray
2021-08-18 03:12:01 × hueso quits (~root@user/hueso) (Ping timeout: 248 seconds)
2021-08-18 03:14:35 → hueso joins (~root@user/hueso)
2021-08-18 03:17:26 × sim590 quits (~simon@modemcable090.207-203-24.mc.videotron.ca) (Quit: WeeChat 2.9)
2021-08-18 03:19:32 → simon1 joins (~simon@modemcable090.207-203-24.mc.videotron.ca)
2021-08-18 03:19:50 × eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2021-08-18 03:20:08 <lechner> Is there an easier way to write this? mapM_ (putStrLn $) (map ("Need " <>) $ map fromOnly rows
2021-08-18 03:21:21 <c_wraith> well, a left section of ($) is always redundant
2021-08-18 03:21:49 <lechner> point taken
2021-08-18 03:22:12 <c_wraith> and then you have three consecutive maps. well, one is a mapM_, but that could be written as sequence_ . map
2021-08-18 03:22:20 <c_wraith> you can always fuse consecutive maps
2021-08-18 03:22:43 <c_wraith> mapM_ (putStrLn . ("Need " <>) . fromOnly) rows
2021-08-18 03:22:47 <Axman6> that's mapM_ (putStrLn . ("Need "<>) . fromOnly) rows
2021-08-18 03:23:09 Axman6 highfives c_wraith
2021-08-18 03:23:12 × monochrom quits (trebla@216.138.220.146) (Quit: NO CARRIER)
2021-08-18 03:23:24 <lechner> i had a problem with the operator precedence of <> vs unapplied fromOnly
2021-08-18 03:23:41 <lechner> i see
2021-08-18 03:23:47 <lechner> TIL
2021-08-18 03:23:47 <c_wraith> that should be irrelevant when using a section
2021-08-18 03:25:06 <lechner> Axman6: thanks! it must be painful to watch
2021-08-18 03:26:10 × derelict quits (~derelict@user/derelict) (Ping timeout: 240 seconds)
2021-08-18 03:28:05 → monochrom joins (trebla@216.138.220.146)
2021-08-18 03:29:15 <lechner> c_wraith: thank you so much for your help! i have a VALUES vs unnest() problem but will have to solve that later tonight. great progress!
2021-08-18 03:33:27 × zebrag quits (~chris@user/zebrag) (Quit: Konversation terminated!)
2021-08-18 03:35:14 → jamie101 joins (~jamie101@pa49-199-6-183.pa.vic.optusnet.com.au)
2021-08-18 03:39:09 ← jamie101 parts (~jamie101@pa49-199-6-183.pa.vic.optusnet.com.au) ()
2021-08-18 03:47:01 → aarvar joins (~aaron@2601:602:a080:fa0:d9cd:315e:aa0a:fa0)
2021-08-18 03:47:28 × aarvar quits (~aaron@2601:602:a080:fa0:d9cd:315e:aa0a:fa0) (Client Quit)
2021-08-18 03:47:57 × shapr quits (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Ping timeout: 245 seconds)
2021-08-18 03:50:07 → falafel joins (~falafel@2601:483:4e00:2b20:e0f3:c7c1:91ca:fe6e)
2021-08-18 03:50:58 → u0_a253 joins (~u0_a253@2402:9d80:247:f919:764b:d5cb:dc9:2b1d)
2021-08-18 03:51:35 <u0_a253> hello world
2021-08-18 03:54:41 → merijn joins (~merijn@83-160-49-249.ip.xs4all.nl)
2021-08-18 03:55:33 <lechner> Hi, is [1, 2, 3] the same as [(1), (2), (3)] please?
2021-08-18 03:56:02 → eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2021-08-18 03:56:24 <lechner> it's for this with one column https://hackage.haskell.org/package/postgresql-simple-0.6.4/docs/Database-PostgreSQL-Simple-Types.html#t:Values
2021-08-18 03:58:24 → bitdex joins (~bitdex@gateway/tor-sasl/bitdex)
2021-08-18 03:59:14 × bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2021-08-18 04:00:03 → bitdex joins (~bitdex@gateway/tor-sasl/bitdex)
2021-08-18 04:02:53 → mei joins (~mei@user/mei)
2021-08-18 04:04:07 <int-e> lechner: yes to your question, but it's not applicable to the documentation, which has a list of tuples, more like [(1,2), (3,4)]
2021-08-18 04:04:25 <int-e> > length [(1,2),(3,4)]
2021-08-18 04:04:27 <lambdabot> 2
2021-08-18 04:04:44 <lechner> int-e: what if my tuples contain only one element each?
2021-08-18 04:05:03 <int-e> > [(1),(2),(3),(4)]
2021-08-18 04:05:05 <lambdabot> [1,2,3,4]
2021-08-18 04:05:16 <int-e> I already said yes :-/
2021-08-18 04:06:03 → severen joins (~severen@202.36.179.72)
2021-08-18 04:07:02 <lechner> am i not doing the same thing as the example? https://paste.debian.net/1208072/
2021-08-18 04:12:04 × pavonia quits (~user@user/siracusa) (Quit: Bye!)
2021-08-18 04:17:09 <oak-> >[(1,),(2,),(3,),(4,)]
2021-08-18 04:17:33 <oak-> > [(1,),(2,),(3,),(4,)]
2021-08-18 04:17:35 <lambdabot> error:
2021-08-18 04:17:35 <lambdabot> • No instance for (Typeable t0)
2021-08-18 04:17:35 <lambdabot> arising from a use of ‘show_M72548533020348860047’
2021-08-18 04:18:11 <glguy> > (1,) 2
2021-08-18 04:18:13 <lambdabot> (1,2)
2021-08-18 04:18:59 <glguy> > (,1) 2
2021-08-18 04:19:01 <lambdabot> (2,1)
2021-08-18 04:20:39 × severen quits (~severen@202.36.179.72) (Quit: WeeChat 3.2)
2021-08-18 04:22:33 ← ahlk parts (~user@2600:1700:31c0:3a10::48) (ERC (IRC client for Emacs 26.1))
2021-08-18 04:22:54 <int-e> https://hackage.haskell.org/package/postgresql-simple-0.6.4/docs/Database-PostgreSQL-Simple.html#t:Only
2021-08-18 04:23:01 <int-e> lechner: ^^
2021-08-18 04:24:39 <int-e> (which I found via the list of instances of ToRow)
2021-08-18 04:28:40 × merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2021-08-18 04:32:33 × wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 248 seconds)
2021-08-18 04:39:58 → derelict joins (~derelict@user/derelict)
2021-08-18 04:44:12 × derelict quits (~derelict@user/derelict) (Ping timeout: 245 seconds)
2021-08-18 04:44:16 × marinelli[m] quits (~marinelli@2001:470:69fc:105::2d8) (Quit: Reconnecting)
2021-08-18 04:44:31 → marinelli[m] joins (~marinelli@2001:470:69fc:105::2d8)
2021-08-18 04:51:13 → wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
←Prev  Next→
Page 1 .. 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 .. 18042

All times are in UTC.