@bglbgl gwyng 아무래도 Gemini 시리즈가 컨텍스트 윈도가 길어서 그런 것도 큰 것 같아요. 다른 모델은 중간에 compaction을 해야 하니까 아무래도 대화가 길어지면 손실이 있고 말이죠.

bgl gwyng
@bgl@hackers.pub · 93 following · 117 followers
GitHub
- @bglgwyng
@hongminhee洪 民憙 (Hong Minhee) 아항 그렇군요. 근데 제가 대화양을 컨텍스트 윈도에 잘 대응을 못시키겠네요. 정말 다른 모델은 컨텍스트 윈도가 이미 꽉찼을만큼 대화가 긴건 아니었다고 생각햇는데요. 이것도 토큰수를 직접 세보기 전엔 모르겠네요.
Gemini Pro 2.5 엄청 똑똑하다... 기존 모델들은 대화가 길어지고 내용이 깊어지면 그냥 뻔한소리를 반복하기 시작하던데, 얘는 계속 생각해서 아이디어를 살려준다.
Body Doubling(모각코, 모각작)이 ADHD인이 작업을 끝내는데 도움이 된다는 내용
@kodingwarriorJaeyeol Lee 오... 느낌이 사실이었군요
Body Doubling(모각코, 모각작)이 ADHD인이 작업을 끝내는데 도움이 된다는 내용
일본에 Fediverse Linux Users Group이라는 모임이 있는데, 거기서 〈국한문혼용체에서 Hollo까지〉라는 이상한 주제로 오늘 발표를 합니다…
RE: https://hollo.social/@hongminhee/019603c7-b5ef-7d81-bbd4-4c37d46edce9
本日開催する第8回FediLUG勉強会に私もオンラインで参加します!「国漢文混用体からHolloまで」というタイトルで発表します。よろしくお願いします。
일본에 Fediverse Linux Users Group이라는 모임이 있는데, 거기서 〈국한문혼용체에서 Hollo까지〉라는 이상한 주제로 오늘 발표를 합니다…
RE: https://hollo.social/@hongminhee/019603c7-b5ef-7d81-bbd4-4c37d46edce9
@bglbgl gwyng 저 블로그 가꾸고, 메일 서버는 예전에 sendmail. qmail. postfix 돌렸었는데, 지금은 서버가 없어 돌리진 않고 있습니다. 저 호감인가요? ㅎㅎ
@lionhairdino 물론이지요ㅎㅎ 잘 보고 있습니다
설치형으로 블로그 만들어서 가꾸고, 메일 서버도 직접 띄워서 쓰고 이런 개발자들보면 왠지모를 호감이 간다. 근데 막상 나는 저런거 귀찮아서 절대 안하고 맨날 공짜만 찾아다닌다.
주로 hackers.pub에 서식하고 있고, 개발 얘기는 주로 여기(@kodingwarrior@hackers.pubJaeyeol Lee)에서 하게 될 것 같습니다. 연친소를 쓰고 있는 이 계정은 사담용!
한국 연합우주 개발자 모임(https://fedidev.kr)
한국어권 Vim 사용자 모임(https://vim.kr)
각각의 커뮤니티에서 취미로 모더레이터를 하고 있습니다.
(굳이 언급하자면) 개발하는 분야는 백엔드 프론트엔드 가리지 않아왔지만, 현재는 프론트엔드에 집중하고 있음!
---
개발자가 아닌 나라는 사람에 대해서 소개하자면,
애니메이션 좋아하고!
넷플릭스에서 영화/드라마 보는거 좋아하고!
어쩌다보니 마작도 하게 되어서 맛들렸고!
듀오링고도 쫌좀따리도 돌리는!
평범한 사람입니다. 혼자 코인노래방가서 노래부르는 것도 좋아하는데, 저랑 노래방 같이 가는 분이 계신다면 저의 퍼포먼스를 가장한 재롱잔치를 보는 진귀한 광경을 체험하실 수 있읍니다
타임라인에 Gumroads가 있길래 오랜만에 들어가봤습니다. 이곳은 전에 유명한 하스켈 책을 팔던 곳인데 지금은 없네요. 대신 @bglbgl gwyng 님이 좋아하실만한 걸 찾았습니다.
https://abuseofnotation.github.io/category-theory-illustrated/
@curry박준규 감사합니다!!
타임라인에 Gumroads가 있길래 오랜만에 들어가봤습니다. 이곳은 전에 유명한 하스켈 책을 팔던 곳인데 지금은 없네요. 대신 @bglbgl gwyng 님이 좋아하실만한 걸 찾았습니다.
https://abuseofnotation.github.io/category-theory-illustrated/
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
> Ops엔지니어: 서버 코스트를 대폭 아꼈습니다
> 매니저: 오 어떻게 하셨나요
> Ops엔지니어: 민주주의 했습니다
https://x.com/integraldx_dev/status/1907988238863630662
해키지(Hackage)[1]에 패키지를 업로드하면 자동으로 빌드, 문서 생성, 테스트가 진행된다. 그런데 이게 시간이 좀 걸린다.(체감상 10분 정도) 이 과정이 자동으로 완료되기 전에 참지 못하고 수동으로 문서를 업로드하면 자동으로 진행되던 것들이 모두 중단된다. https://github.com/haskell/hackage-server/issues/1376
하스켈 패키지 저장소 ↩︎
bgl gwyng shared the below article:
닉스의 derivation 생성식과 derivation의 차이

lionhairdino @lionhairdino@hackers.pub
이 글은 Nix를 처음 접하는 사람들을 위해 `derivation` 개념을 명확히 하고자 합니다. Nix에서 `derivation`은 패키지 빌드를 위한 명세서로 간단히 설명되지만, 실제로는 `derivation 생성식`과 `derivation 객체`를 구별하는 것이 중요합니다. Nixpkgs는 `derivation` 자체가 아닌 `derivation 생성식(.nix)`들의 모음이며, 이 생성식을 평가해야 `derivation`이 만들어집니다. `.drv` 파일은 평가 결과를 캐싱한 파일입니다. 저자는 Nix가 의존성들을 `derivation 생성식`들의 관계로 표현하고, 최종적으로 하나의 생성식이 하나의 패키지를 표현한다는 점을 강조합니다. 흔히 `derivation`이라 부르는 것은 런타임에 메모리에 올라온 `derivation 데이터 타입` 객체이며, 이는 `derivation 생성식`을 평가한 결과입니다. 이러한 구분을 통해 Nix 코드를 함수형 관점에서 더 명확하게 이해할 수 있다고 주장합니다. Nix의 `derivation` 개념을 더 깊이 이해하고 싶다면 이 글이 좋은 출발점이 될 것입니다.
Read more →진짜 이건 명 짤이다
조던 엘렌버그라는 수학자가 쓴 '틀리지 않는 법'이란 책이 있는데, 재밌고 읽어볼만하다.
그 책에서 컴퓨터가 수학자가 하던일을 할수 있게되면 어떡하냐에 대해 저자의 해결책을 제시하는데 원래 하던일을 컴퓨터한테 맡기고 수학자들은 더 고차원적인 일을 하면 된다고 한다. 한 10년 전에 읽었을때도 그냥 대책없고 나이브한 생각으로 보였다. 근데 요즘은 (실제로 어떻게 될지랑은 상관없이) 저런 나이브한 마음가짐을 일부러라도 가지고 일해야 뭐라도 해낼듯.
향후 10여년 간 AI가 일으킬 변화는 산업혁명을 능가할 것이다. 샘 올트먼은 OpenAI가 "진정한 의미의 초지능"과 "영광스러운 미래"를 목표로 한다고 말했다. 그 미래는 어떤 모습일까? 이에 답하기 위한 시나리오. https://ai-2027.com/
오늘이 첫 번째 서울하스켈숲 워크샵이었을텐데 어땠을지 너무 궁금하다. 어디 후기 안 올라오려나⋯
RE: https://hackers.pub/@curry/0195d0ee-d8d2-7711-b550-b54cc1b5d599
오늘이 첫 번째 서울하스켈숲 워크샵이었을텐데 어땠을지 너무 궁금하다. 어디 후기 안 올라오려나⋯
RE: https://hackers.pub/@curry/0195d0ee-d8d2-7711-b550-b54cc1b5d599
@bglbgl gwyng 잘 모릅니다... ㅋㅋㅋ 제 원래 필드 자체가 정형명세를 메인으로 하는 동네가 아니라서요. 순수 도파민 목적으로만 가끔 하는 정도입니다.
@noxowlSuyeong RHIE 아하 그렇군요. https://discord.gg/KuzFFerB 그래도 혹시 심심하시면 오셔서 공부도 같이하시고 하면 좋을거 같습니다.
@bglbgl gwyng 네 직접 논리를 정의해서 쓰시면 할 수 있습니다. 수업에서는 뮤텍스 프로토콜 검증을 위한 증명을 했었고요. GitHub나 논문 발표 선에서 동시성이나 암호화 관련 증명하는데 가끔 보이는 것 같습니다. 저도 인터랙션 플로우를 상상하며 정의할 때 엣지케이스를 미리 시뮬레이션(물론 현실은 쉽지 않음) 해 보는데 활용합니다.
@noxowlSuyeong RHIE 오호 흥미롭네요. 혹시 'Pnv-증명언어 및 정형검증 커뮤니티' 라는 디스코드 서버를 알고 계실까요?
@noxowlSuyeong RHIE algebraic specification language! 혹시 이거 세션 타입과도 관련이 있나요?
@bglbgl gwyng 네 직접 논리를 정의해서 쓰시면 할 수 있습니다. 수업에서는 뮤텍스 프로토콜 검증을 위한 증명을 했었고요. GitHub나 논문 발표 선에서 동시성이나 암호화 관련 증명하는데 가끔 보이는 것 같습니다. 저도 인터랙션 플로우를 상상하며 정의할 때 엣지케이스를 미리 시뮬레이션(물론 현실은 쉽지 않음) 해 보는데 활용합니다.
@hongminhee洪 民憙 (Hong Minhee)
@kodingwarriorJaeyeol Lee 해시태그는 ActivityPub의 어떤 개념에 대응되나요? 또는 그냥 별개인건가요?
@kodingwarriorJaeyeol Lee 아직 안 됩니다… 이것도 얼른 지원해야겠네요.
@hongminhee洪 民憙 (Hong Minhee)
@kodingwarriorJaeyeol Lee 해시태그는 ActivityPub의 어떤 개념에 대응되나요? 또는 그냥 별개인건가요?
해커스펍 친구를 소개합니다 줄여서 해친소
이러면 hurted cow로 읽힐 것 같다
실용적인 프로그램을 만들 수는 없겠지만, Maude와 같은 정형 명세 언어도 재미있습니다. 저는 실제 코드를 쓰기 전에 데이터 흐름을 정리하고 추상화 하여 스펙을 명확히 하는데 사용합니다. 단점은 GitHub에서 무슨 언어인지 몰라서 통계가 안 잡힙니다.
@noxowlSuyeong RHIE algebraic specification language! 혹시 이거 세션 타입과도 관련이 있나요?
bgl gwyng replied to the below article:
셸 언어는 때로 추하길 요구 받는다

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
이 글에서는 명령줄 인터페이스(CLI)를 지배하는 셸 언어의 독특한 설계 철학을 탐구하며, 셸 언어가 왜 때로는 "추함"을 받아들여야 하는지에 대한 이유를 설명합니다. Bash와 PowerShell을 비교하며, PowerShell이 가독성을 높이기 위해 장황해진 반면, Bash는 간결함을 유지하여 빠른 상호작용에 더 적합함을 지적합니다. 현대적인 셸인 Nushell이 이 균형을 맞추기 위해 노력하는 점을 언급하며, 셸 언어의 성공은 "아름다운 코드"와 "효율적인 상호작용" 사이의 균형에 달려 있음을 강조합니다. 마지막으로, 모든 도구는 사용 맥락에 맞게 설계되어야 한다는 더 넓은 소프트웨어 설계 원칙을 제시하며, 셸 언어의 맥락은 키보드와 사용자 사이의 빠른 대화임을 강조합니다. 이 글은 셸 언어 설계에 대한 흥미로운 통찰력을 제공하며, 소프트웨어 설계 시 맥락의 중요성을 일깨워 줍니다.
Read more →@hongminhee洪 民憙 (Hong Minhee) 근데 또 말씀하신 문제들이 autocompletion 잘되면 어느정도 해결되지 않나요?
실용적인 프로그램을 만들 수는 없겠지만, Maude와 같은 정형 명세 언어도 재미있습니다. 저는 실제 코드를 쓰기 전에 데이터 흐름을 정리하고 추상화 하여 스펙을 명확히 하는데 사용합니다. 단점은 GitHub에서 무슨 언어인지 몰라서 통계가 안 잡힙니다.
bgl gwyng shared the below article:
셸 언어는 때로 추하길 요구 받는다

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
이 글에서는 명령줄 인터페이스(CLI)를 지배하는 셸 언어의 독특한 설계 철학을 탐구하며, 셸 언어가 왜 때로는 "추함"을 받아들여야 하는지에 대한 이유를 설명합니다. Bash와 PowerShell을 비교하며, PowerShell이 가독성을 높이기 위해 장황해진 반면, Bash는 간결함을 유지하여 빠른 상호작용에 더 적합함을 지적합니다. 현대적인 셸인 Nushell이 이 균형을 맞추기 위해 노력하는 점을 언급하며, 셸 언어의 성공은 "아름다운 코드"와 "효율적인 상호작용" 사이의 균형에 달려 있음을 강조합니다. 마지막으로, 모든 도구는 사용 맥락에 맞게 설계되어야 한다는 더 넓은 소프트웨어 설계 원칙을 제시하며, 셸 언어의 맥락은 키보드와 사용자 사이의 빠른 대화임을 강조합니다. 이 글은 셸 언어 설계에 대한 흥미로운 통찰력을 제공하며, 소프트웨어 설계 시 맥락의 중요성을 일깨워 줍니다.
Read more →해커스펍 성장하는걸 구경하는 재미가 있어서 슥뽕슥뽕하게 됨
역시 모든 것들은 직접 데여봐야 는다... React의 useContext가 뭐하려고 쓰는지 실감이 잘 안났었는데, prop drilling하지 않고 디펜던시를 주입하고 싶을때 유용한듯.
특히, 어떤 특정한 데이터를 다루는 복잡한 컴포넌트를 다룬다고 가정하면 요렇게 프로바이더에 넘겨주면 되고 하위 컴포넌트에서는 useContext에서 그 값을 가져오면 코드도 굉장히 깔끔해지게 되는 듯
<PostContext.Provider value={{ currentUser }}>
<Post.Title post={post} />
<Post.Comments>
{comments.map(comment =>
<Post.Comment comment={comment} />
)}
</Post.Comments>
<PostContext.Provider>
이런 글도 있다.
https://testdouble.com/insights/react-context-for-dependency-injection-not-state-management
Hackers' Pub에 이제 알림 기능이 생겼습니다. 우상단 프로필 사진 바로 왼쪽에 알림 아이콘이 추가되었고, 이제 읽지 않은 알림이 있을 경우 그 위에 빨간 동그라미가 표시됩니다. 알림의 종류는 현재 다음 다섯 가지입니다:
- 누가 날 팔로했을 때
- 누가 날 언급했을 때
- 누가 내 글에 답글을 달았을 때
- 누가 내 글을 인용했을 때
- 누가 내 글을 공유했을 때
소수의견: 프로그래밍 언어의 identifier에서 그냥 소문자만 남기고 대문자를 아예 금지시켜야한다. 그리고 하이픈이나 언더바 둘중에 하나만 허용한다. 둘다 허용하면 취향에 따라 섞어쓰게된다. 진작에 이렇게 했으면 뭐시기 case 논쟁으로 시간낭비 안 했을것이다.
그리고 남은 대문자를 identifier와 충돌할 걱정없이 자유롭게 keyword에 쓰면 된다. 내가 생각하는 멋진 응용으로는, 객체 생성에 대표적으로 쓰이는 new
대신에 A
를 쓰는 것이다. x = A user
, 쏘쿨하지 않습니까.
@bglbgl gwyng
@curry박준규 네, 이 친구의 경우에는 고등학생 때 잠깐 C++을 했었고, 그 뒤에 전혀 다른 일(장사 등)을 하다가 몇 해 전에 다시 프로그래밍을 시작하여 Python → Go → Rust 순서로 옮겨 탔다고 하더라고요. Haskell은 Rust를 접한 뒤에 이름을 들어 보았다고 합니다.
@hongminhee洪 民憙 (Hong Minhee)
@curry박준규 저도 C/C++만 하다가, 취직해서 Python/C# 등등 메모리 관리 알아서 해주는 언어의 편리함을 제대로 느꼈거든요. 그런 다음에 Rust 나왔을때 다시 메모리 관리하려고 하니까 너무 불편하고 이런걸 꼭 해야하나 싶었습니다. 요즘은 하스켈로 space leak 와장창 내면서 살고 있습니다ㅋㅋ
@curry박준규 굉장히 흥미로워 했어요.
@hongminhee洪 民憙 (Hong Minhee)
@curry박준규 제가 Rust 유저한테 하스켈을 영업해본적은 없지만, Rust 유저들은 하스켈을 고를수 있는 선택지에서 이미 결정을 내리고 지나온 사람들이라고 생각했거든요. HKT, 모나드? 그런거보다 포인터 직접 만지고 최적화하는게 좋아.
근데 생각해보니 Rust가 언어덕후들이 파던 언어였던것도 이미 오래전 얘기고, 이제는 하스켈 등의 옵션을 고려하지 않은채로 Rust를 써야할 환경에 놓인 사람들도 많겠다 싶네요.
해커스 펍에 남기는 첫 글로 진.짜. 술을 파는 해커스 펍을 소개하겠습니다… 도쿄 히가시나카노에 위치한ハッカーズバー(hackers bar)에 가시면 바텐더 분의 라이브코딩을 구경하며 블루스크린, 커널 패닉 등의 이름이 붙여진 칵테일을 마실 수 있어요… 모두가 각자의 랩탑을 들고 와서 자유롭게 코딩하고 이야기 나누는 분위기! 도쿄에서 손에 꼽게 인상적이었던 바였습니다. 도쿄에서 술도 마시고 코딩도 하고 싶으신 분들은 한 번 들러보심이~~!
할 말 없으니까 그나마 기술적인 내용이 있는 거 갖고오기: React로 게임 프로토타이핑하기
bgl gwyng shared the below article:
함수형 프로그래머한테 닉스 패키지 매니저의 derivation 소개하는 글

lionhairdino @lionhairdino@hackers.pub
이 글은 닉스의 핵심 개념인 derivation에 대해 설명합니다. Derivation은 패키지 빌드에 필요한 속성들의 집합으로, 닉스는 이를 통해 의존 관계를 순수하게 표현합니다. 패키지 A가 B에 의존한다면, A의 derivation이 B의 derivation에 의존하는 방식으로 명세서를 작성하고, 실제 패키지가 필요할 때 realize 동작을 통해 이펙트들의 영향을 받습니다. 이러한 선언적인 명세서 덕분에 닉스는 선언형 패키지 매니저라고 불립니다. Derivation 이름에 내용 기반 해시를 붙여 캐싱과 재현성을 높이지만, 작은 변화에도 해시값이 달라져 디스크 용량과 빌드 시간이 늘어나는 단점도 있습니다. Nixpkgs는 derivation 자체가 아닌, derivation을 생성하는 표현식들의 모음으로 구성됩니다.
Read more →빨리 팀을 만들어서 일정도 짜고 회고도 하고 회식도 하고 했으면 좋겠다. 그러기위해 어서 MVP를 완성하자.
Hackers' Pub 행동 강령을 관통하는 큰 키워드가, 존중과 배려라고 느꼈고, 그래서 더욱 Hackers' Pub 을 응원하고 있는데, 오랜 시간이 흘러도 추구하는 가치에 흔들림이 없으면 좋겠고, 여기에 더해 긍정적이고 밝은 에너지가 가득한 공간이 되기를 소망한다.
한가지만 더 첨언하자면, 개발자의 소소한 일상 얘기들도 많이 공유되었으면 좋겠다. (우선 나부터도 해야겠지만)
bgl gwyng shared the below article:
deno-task-hooks: Git 훅을 Deno 태스크로 쉽게 관리하기

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
안녕하세요! 오늘은 제가 개발한 deno-task-hooks 패키지를 소개해 드리려고 합니다. 이 도구는 Deno 태스크를 Git 훅으로 사용할 수 있게 해주는 간단하면서도 유용한 패키지입니다.
어떤 문제를 해결하나요?
Git을 사용하는 개발 팀에서는 코드 품질 유지를 위해 커밋이나 푸시 전에 린트, 테스트 등의 검증 작업을 실행하는 것이 일반적입니다. 이러한 작업은 Git 훅을 통해 자동화할 수 있지만, 기존 방식에는 몇 가지 문제가 있었습니다:
- Git 훅 스크립트를 팀원들과 공유하기 어려움 (.git 디렉토리는 보통 버전 관리에서 제외됨)
- 각 개발자가 로컬에서 훅을 직접 설정해야 하는 번거로움
- 훅 스크립트의 일관성 유지가 어려움
deno-task-hooks는 이러한 문제를 해결하기 위해 Deno의 태스크 러너를 활용합니다. Deno 태스크는 deno.json 파일에 정의되어 버전 관리가 가능하므로, 팀 전체가 동일한 Git 훅을 쉽게 공유할 수 있습니다.
어떻게 작동하나요?
deno-task-hooks의 작동 방식은 간단합니다:
- deno.json 파일에 Git 훅으로 사용할 Deno 태스크를 정의합니다.
hooks:install
태스크를 실행하면, 정의된 태스크들이 자동으로 .git/hooks/ 디렉토리에 설치됩니다.- 이후 Git 작업 시 해당 훅이 트리거되면 연결된 Deno 태스크가 실행됩니다.
설치 및 사용 방법
1. hooks:install 태스크 추가하기
먼저 deno.json 파일에 hooks:install
태스크를 추가합니다:
{
"tasks": {
"hooks:install": "deno run --allow-read=deno.json,.git/hooks/ --allow-write=.git/hooks/ jsr:@hongminhee/deno-task-hooks"
}
}
2. Git 훅 정의하기
Git 훅은 hooks:
접두사 다음에 훅 이름(케밥 케이스)을 붙여 정의합니다. 예를 들어, pre-commit
훅을 정의하려면:
{
"tasks": {
"hooks:pre-commit": "deno check *.ts && deno lint"
}
}
3. 훅 설치하기
다음 명령어를 실행하여 정의된 훅을 설치합니다:
deno task hooks:install
이제 Git 커밋을 실행할 때마다 pre-commit
훅이 자동으로 실행되어 TypeScript 파일을 검사하고 린트 검사를 수행합니다.
지원되는 Git 훅 종류
deno-task-hooks는 다음과 같은 모든 Git 훅 타입을 지원합니다:
applypatch-msg
commit-msg
fsmonitor-watchman
post-update
pre-applypatch
pre-commit
pre-merge-commit
pre-push
pre-rebase
pre-receive
prepare-commit-msg
push-to-checkout
sendemail-validate
update
이점
deno-task-hooks를 사용하면 다음과 같은 이점이 있습니다:
- 간편한 공유: Git 훅을 deno.json 파일에 정의하여 팀 전체가 동일한 훅을 사용할 수 있습니다.
- 설정 용이성: 새 팀원은 저장소를 클론한 후 한 번의 명령어로 모든 훅을 설치할 수 있습니다.
- 유지 관리 용이성: 훅 스크립트를 중앙에서 관리하므로 변경 사항을 쉽게 추적하고 적용할 수 있습니다.
- Deno의 안전성: Deno의 권한 모델을 활용하여 훅 스크립트의 보안을 강화할 수 있습니다.
마치며
deno-task-hooks는 작은 패키지이지만, Git과 Deno를 함께 사용하는 팀의 개발 경험을 크게 향상시킬 수 있습니다. 코드 품질 유지와 개발 워크플로우 자동화를 위해 한번 사용해 보세요!
패키지는 JSR에서 다운로드할 수 있으며, GitHub에서 소스 코드를 확인할 수 있습니다.
피드백과 기여는 언제나 환영합니다! 😊
일정 추산은 어려운 일이다. TWP(Two-Week Principle)는 모든 시간 참조를 표준화하는 새로운 시간 척도다. 이 제안에 따르면 시간과 관련된 모든 질문에 반사적으로 "2주"라고 응답해야 한다. https://www.rfc-editor.org/rfc/rfc9759
아잇 오늘 확인해보니까
- emacs native-comp 잘 쓰고 있던 메인 맥은 macOS 15.3
- 새로 세팅한 맥은 하필 어제 업데이트를 누르는 바람에, 하필 어제 릴리즈된 macOS 15.4를 깔아버린 것
어쩐지 이슈가 없더라
@nyeongAn Nyeong (安寧) macOS 업데이트... 개발자들에겐 주기적으로 찾아오는 재앙이지요
슈티를 그냥 Misskey 클라이언트로 만들어 버릴까...
요즘 OTT에서 미드보다 보면(영드,한드 보다 특히 미드) 정말 질떨어지는 시나리오들이 많다. 제대로된 갈등 구조도 없이, 그냥 성질 더럽고 의사소통 못하는 캐릭터들을 다수 등장시켜 걔네들끼리 언성높이고 투닥거리는 걸로 시간을 다 보낸다.
@bglbgl gwyng 어라 Cabal이 기본적으로 스냅숏 모드로 동작하나요? Stack만 쓴 지 몇 년 되어서 Cabal이 그랬던가 기억이 가물가물하긴 한데요…
@hongminhee洪 民憙 (Hong Minhee) 음 표현이 좀 잘못된거 같네요. 버전에 constraint들 명시하면 그거 resolve해서 설치하겠죠. 제가 말하려고 했던건 lock이 개별 패키지 별로 안남고
indexed-state
로 스냅샷 시간을 명시하는 방식이 마음에 안든가 거였습니다. cabal.freeze 또한 암호해시가 안 남고요.
해커스펍이 하스켈로 테라포밍되고 있어...!! 이렇게 된 이상 하스켈 학교에서 대량으로 모셔와야만..!!
근데 cabal처럼 기본이 스냅샷 모드인건 별로 같다. cabal로 locking하려면 시간으로(스냅샷을 특정할) 해야한다;; npm같이 각 패키지 버전과 lock이 있는 편이, 일단 심리적으로 더 든든하고, 또 가장 원자적인 동작을 더 확실하게 만든단 점에서 좋다.
대신 그 위에서 스냅샷(이라고 해야하나, 다른 이름이 있던거 같기도한데)을 다시 구현할수 있다. Expo같은 경우에 expo 패키지에 따라 나머지 expo-* 들의 버전이 결정되도록 한다.