Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Gábor Bakos
@aborg0
Lehet, hogy a lehetséges null érték miatt van.
(puffnfresh/wartremover#175)
Gábor Bakos
@aborg0
Szerinted mi néz ki jobban:
@SuppressWarnings(Array("org.brianmckenna.wartremover.warts.NonUnitStatements")) az ellenőrzött metódusokon, vagy
{val _ = (m_values.remove( m_values.size - 1 ) )}, vagy
discard{ m_values.remove( m_values.size - 1 ) }? (Szeretném megtartani a NonUnitStatements wart-ot.)
szabivan
@szabivan
hm, érdekes
de a case _ => None fix szerintem nem árthat, futásidőnek biztos nem (hisz nem fut oda a vezérlés)
I'm for discard
Gábor Bakos
@aborg0
Persze az is opció, hogy maradjon a warning.
szabivan
@szabivan
jobb szeretnék én is minél több warningtól megszabadulni, amíg az nem jár túl nagy pluszmunkával, szerintem a discard jó lesz
Gábor Bakos
@aborg0
ok
szabivan
@szabivan
és akkor konvencióként mostantól így csinálom
Gábor Bakos
@aborg0
Azért várd meg míg committolom a discard metódust. ;)
szabivan
@szabivan
sőt, még pullolok is egyet előtte :D
a mutable package-gel van valami terved? úgy hiszem, ugyanúgy kéne kezelni, mint a vart, ezek kéz a kézben járnak
Gábor Bakos
@aborg0
Kivettem a wart-ok közül.
szabivan
@szabivan
ok, thx
Gábor Bakos
@aborg0
Mivel szeretném ha esetleg később futna Scala.js felett is, így inkább scala mutable mint Java.
szabivan
@szabivan
jogos, én is minél kisebbre képzelem venni a java részt - ha azt mondod, az Enumnál az a jobb, akkor ott jöhet az enum, de egyébként csak ha nagyon muszáj
Gábor Bakos
@aborg0

(Átírom ezt:

    val idx : Int = m_valuesToIndices.remove( value ) match { case Some( n ) => n; case None => -1 }

erre

    val idx : Int = m_valuesToIndices.remove( value ).getOrElse(-1)

)

szabivan
@szabivan
getOrElse! okay
Gábor Bakos
@aborg0
(Tesztekben lehet életszerűbb lesz majd a @SuppressWarnings(Array("org.brianmckenna.wartremover.warts.NonUnitStatements")). Egyelőre mind discard lesz, de könnyen lehet, hogy célszerűbb ott erre nem figyelni.)
szabivan
@szabivan
van egy osztály, tkp egy darab union egy csomó getterrel meg getType()-al (a sat/watched). Ahogy látom, az elérések mint switch(getType())-al kezdenek és típusfüggően az unió adott típusra értelmes gettereit használják. Amennyit a scalaról eddig tudok, az alapján ez pont az, amire a case classt kitalálták, igaz?
Gábor Bakos
@aborg0
Pontosan. Az unapply-t generálja. Ha gondolod esetleg egy ős sealed trait-et mögéjük tehetsz, ha másért nem, hogy jelezze nem csak egy AnyRef-et vár/ad.
szabivan
@szabivan
Persze, az kell is, az lenne maga a Watched, és ezalatt a final case classok BinaryWatched, TernaryWatched etc
ez a scalás pattern matching tetszik
Gábor Bakos
@aborg0
(Majd a util/util.scala file-t lehet érdemesebb lenne átnevezni mondjuk LBool.scala-ra.)
(Az implicit numeric widening nem tudom hogy jött be.)
szabivan
@szabivan
legalábbis a LBool-t átemelni belőle egy külön LBool.scala-ba, a type Vectort otthagynám.
eredetileg az LBool is csak egy type LBool = Option[Boolean] volt, aztán mikor az több sebből elkezdett vérezni, lett belőle trait+case object, de nem raktam át új fileba
Gábor Bakos
@aborg0
A Vector-t már áttettem a package.scala file-ba.
szabivan
@szabivan
oh yes, azt mondtad is, hogy új volna jó, elfelejtettem :S
szabivan
@szabivan
és akkor gondolom sbt újragenerálás
Gábor Bakos
@aborg0
Yes sir.
szabivan
@szabivan
roger that
remélem nem toltam el a mergelést
Gábor Bakos
@aborg0
Volt conflict?
szabivan
@szabivan
egen, közben piszkáltam a Heapet én is egy kicsit
meg valamiért conflictnak jelezte, hogy áttetted a vectort máshova
Gábor Bakos
@aborg0
Nem tudom pontosan, hogy az evaluate-et szeretnéd-e máshol/másként használni, de lehet praktikusabb lenne kétparaméteresként definiálni.
Gábor Bakos
@aborg0
Itt szerintem használhattál volna ==-t is. (Scalaban az nem a referencia szerinti összehasonlítás, arra ott az eq.)
szabivan
@szabivan
(jogos, valahol korábban azt olvastam, hogy avoid ==, ha van Java meg scala kód is, hogy ne keverjék össze a devek, hogy épp melyik szemantikája van az ==-nek.)
(egyébként van egy ClauseAllocator struct, osztály vagy valami, ami inteket castol pointerekké meg vissza, memóriamanagerkedés ,ezt akarom kiváltani valahogy épp most)
Gábor Bakos
@aborg0
Remek, köszi. Úgy tűnik sf.net is összekapta magát, de erre a coveralls.io ami lassú. Hogy fog így a teszt-lefedettség megjelenni a neten? De legalább most már lehet tesztelni, hogy mi működhet. :)
Ezek szerint a ClauseAllocator eléggé C-s szemléletben készült. Jó lenne nem írni egy memory manager-t.
szabivan
@szabivan
semmiképp. Amire eddig sikerült rájöjjek, az az, hogy a ClauseAllocator szerez egy jó nagy memory chunkot és azon belül intézi a (különböző méretű, memóriát tekintve is) klózoknak szükséges memória managementet, de (mivel maga a struct nem immutable, pl ugyanolyat is létrehoz simán, mint ami már van nála beregisztrálva) semmi olyat nem csinál, amit a JVM ne csinálna meg szerintem legalább olyan jól (amennyire tudom, a JVM is jól be van idomítva arra, hogy sok kicsi objektumot manageljen), ezért a JVM-re bíznám a dolgot.
Most két megoldás van (a cpp-ben van a clause és a clauseoffset típus, előbbi struct, utóbbi int, és az allocatoron keresztül megy a konverzió, ami tkp egy void* <-> unsigned int cast) az egyszerűbb az lenne, hogy egy Int->Clause mapot hívni allokátornak, de ez nekem egyáltalán nem tetszik, helyette inkább egyesíteném a clause és a clauseoffset típust (mmint meghagynám a ClauseOffset type-ot, de nem UInt-nek vagy mi most, hanem Clause-nak) és kihagynám az egész allocatoros történetet (ez viszont, mivel pár helyen arra számít, hogy a clauseoffset az egy unsigned int, okozhat kellemetlen helyzetet a portolásnál, ha valami bitlevel hackokat is csinál rajta valahol. doksi híján nem világos.)
(nem merném a Clause osztály t használni mindenhol, ahol ClauseOffset kell, mert ha később mégiscsak valahogy kiderül, hogy kell az a ClauseOffset, akkor nagyon nehéz lenne visszanyerni, hogy melyik volt eredetileg Clause és melyik ClauseOffset. csak letype-olnám a ClauseOffset-et Clause-nak)
Gábor Bakos
@aborg0
Készíthetsz egy type-alias-t vagy import átnevezést és használhatod a ClauseOffset-et ahol azt látod a C++ kódban, de amíg nem jelent gondot, addig Clause-t jelentené. Ha mégis kellene, akkor egyszerűen be lehetne vezetni ClauseOffset-et.
szabivan
@szabivan
épp erre gondoltam a "meghagynám a ClauseOffset typeot [..] Clause-nak" résznél (type alias)
..amit megelőzően portolom (épp) magát a Clause osztályt
Gábor Bakos
@aborg0
Majd pull-t kérj commit előtt. (Én elfelejtettem, így lett egy merge commitom is.) (Semmi komoly nem volt benne, csak frissítettem a coverage részt, de úgy tűnik nem túl jól sikerült.)
Gábor Bakos
@aborg0
(Tetszik a kódod, köszi az odafigyelést.)
Gábor Bakos
@aborg0
(A coveralls statisztikák nem tökéletesek: 1.2, 1.3 verziójú scoverage nem működik jól együtt az 1.0-s pluginnel. :( Jeleztem a fejlesztők felé, remélhetőleg javítják majd. Mindenesetre biztató, hogy volt olyan állapot, amikor több mint 40%-os volt a tesztek által lefedett kódsorok aránya. :) Szerintem most is akörül lehet.)
Gábor Bakos
@aborg0
Boldog névnapot, kellemes pihenést! :sparkles: (Bocsi, hogy épp ma érdeklődtem.)
Gábor Bakos
@aborg0
Lokálisan lefordult? Úgy tűnik a -Yrangepos lehet a ludas.
Gábor Bakos
@aborg0
Itt lehet, hogy célszerűbb lenne egy to[Vector], akkor talán a compiler sem prüszkölne.
Gábor Bakos
@aborg0
(Javítottam nálunk és scoverage/scalac-scoverage-plugin#129.)
Gábor Bakos
@aborg0
Belenyúltam egy picit a kódodba. Ha valamit rosszul csináltam, nyugodtan visszacsinálhatod, javíthatod.